Linux'ta beklenmeyen kapanmalar

İşletim sisteminden bağımsız olarak tüm bilgisayar sistemlerindeki tüm kapanmaların düzgün (graceful) kapanma olması gerekir. Yarım kalan bir yazma işlemi, kapanmamış dosyalar vs bir sonraki açılışta en basitinden birkaç hata ve disk denetlemesinden, geri getirilemez veri kayıpları ve sistemin tekrar kurulmasına kadar sorunları getirebilir.

Beklenmeyen kapanmalar neler olabilir? Bir sistem bileşeni yüzünden sistemin tekrar başlaması (veya sadece kapanması), güç kaybı sebebiyle sistemin kapanması.

last komutuyla sistemdeki açılış ve kapanış olaylarının listesini alabiliriz. Şu kaynakta belirtildiği gibi

$ last -Fxn2 shutdown reboot

-F : Uzun tarih formatı kullan
-x : Kapanma ve çalışma seviyesi değişikliklerini de göster
-n2: En son 2 olayı listele

komudu normal şartlar altında bir kapanışı takip eden bir açılış listelemeli. Eğer normal bir kapanma yoksa iki açılış olayı ile karşı karşıya kalabiliriz. Aşağıdaki çıktıya bakarsak

reboot   system boot  5.9.10-200.fc33. Sun Nov 29 17:09:18 2020   still running
reboot   system boot  5.9.10-200.fc33. Sun Nov 29 16:10:37 2020   still running

16:10'daki açılış da hala "still running" olarak gözüküyor, 17:09'daki açılış da. Bu arada bir beklenmeyen bir kapanış olmuş. Normal bir kapanış ve açılış sonrasında şu gözükür:

reboot   system boot  5.9.10-200.fc33. Sun Nov 29 16:10:37 2020   still running
shutdown system down  5.9.10-200.fc33. Sun Nov 29 01:58:33 2020 - Sun Nov 29 16:10:37 2020  (14:12)

Aynı kaynakta alternatif olarak ausearch aracının kullanılmasından da bahsedilmiş. Örneğin

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

benim normal olarak kapanmayan sistemimde şu sonuçları verdi:

Option ENRICHED not found - line 9
NOTE - using built-in logs: /var/log/audit/audit.log
----
type=SYSTEM_BOOT msg=audit(29-11-2020 13:10:59.324:106) : pid=778 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(29-11-2020 14:09:31.491:105) : pid=793 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

Normal bir kapanış sonrası ise şuna benzer bir kapanış ve sonrasında bir açılış içeren bir çıktı üretmesi gerekirdi:

---
type=SYSTEM_SHUTDOWN msg=audit(29-11-2020 01:58:33.647:1688) : pid=19324 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(29-11-2020 13:10:59.324:106) : pid=778 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

Bu iki durumda da 2 değil 1 satır veri görünüyorsa loglarda bir kalıcılık yoktur, ya da yeterli süre açık kalan bir sistemin son açılış sonrasındaki kayıtları silinmiş olabilir.

Daha ilginç bir çözüm olarak bizim sistemimize özel bir hizmet birimi oluşturmamız önerilmiş. Sadece kapanışta çalılştırılacak /etc/systemd/system/set_gracefulshutdown.service dosyasının içeriği olarak şunlar önerilmiş:

[Unit]

Description=Set flag for graceful shutdown 

DefaultDependencies=no 

RefuseManualStart=true 

Before=shutdown.target

 

[Service] 

Type=oneshot 

ExecStart=/bin/touch /root/graceful_shutdown

 

[Install]

WantedBy=shutdown.target

Daha sonra

$ sudo systemctl daemon-reload

$ sudo systemctl enable set_gracefulshutdown

ile bunlar etkinleştirilmiş. Bu hizmet birimi kapanışta /root/graceful_shutdown dosyası oluşturacak. Ayrıca bir de açılışlarda çalışacak /etc/systemd/system/check_graceful.service hizmet birimi önerilmiş:

[Unit]

Description=Check if previous system shutdown was graceful 

ConditionPathExists=/root/graceful_shutdown 

RefuseManualStart=true 

RefuseManualStop=true

 

[Service]

Type=oneshot

RemainAfterExit=true

ExecStart=/bin/rm /root/graceful_shutdown

 

[Install]

WantedBy=multi-user.target

 

Bu hizmet birimi de açılışta çalışacak ama /root/graceful_shutdown dosyasının varlığı önkoşulu ile. Eğer o dosya yoksa çalışmayacağı için anlayabiliriz ki bir önceki kapanma beklenen bir kapanma değildi. Ayrıca dosya sonraki adımda bu dosyayı sileceği için kapanışta bir dosyanın tekrar oluşturulmasına izin veriyor. Bunu da benzer şekilde enable etmeliyiz:

 

$ sudo systemctl daemon-reload

$ sudo systemctl enable check_graceful

Tereddüt ettiğimizde
 

$ systemctl is-active check_graceful

komutu ile önceki kapanmanın normal olup olmadığını anlayuabiliriz.

En son olarak bir de journalctl ile durum kontorlü önerilmiş.

$ sudo journalctl -b -1 -n

Bu komut, bir önceki boot'ta (-b -1) en son 10 (-n parametresinin varsayılanı 10) kaydını görüntüler. Normal olarak aşağıdakine benzer bir çıktı olması gerekir:

Eyl 06 13:46:58 archbox systemd[1]: Reached target System Shutdown.
Eyl 06 13:46:58 archbox systemd[1]: Reached target Late Shutdown Services.
Eyl 06 13:46:58 archbox systemd[1]: systemd-reboot.service: Deactivated successfully.
Eyl 06 13:46:58 archbox systemd[1]: Finished System Reboot.
Eyl 06 13:46:58 archbox systemd[1]: Shutting down.
Eyl 06 13:46:58 archbox systemd-shutdown[1]: Syncing filesystems and block devices.
Eyl 06 13:46:58 archbox systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Eyl 06 13:46:58 archbox systemd-journald[218]: Received SIGTERM from PID 1 (systemd-shutdow).
Eyl 06 13:46:58 archbox systemd-journald[218]: Journal stopped

Böyle bir durumda aranılan satırlar başarılı olarak kapanmanın ve gerçekleştiğini gösteren (Reached System Shutdown, Finished System Reboot/Shutdown gibi) satırlar ve Journal stopped mesajları olabilir. Benim sistemimde bol hatalı bir çıktı üretti, beklenmeyen kapanmanın göstergesi olarak.

Medya tuşlarıyla videoları kontrol etmemizi sağlayan tarayıcı: Firefox!

Ardı ardına birbirinden güzel özellikler ile karşımıza çıkan açık kaynak kodlu internet tarayıcımız, canımız ciğerimiz: Firefox!

En yeni özelliği yine çok hoşuma gitti. Klavyelerimizde ve kulaklıklarımızda yer alan medya kontrol tuşları ile artık Youtube videolarımızı ve tarayıcımızda oynatılan diğer medyaları kontrol edebiliyoruz.

Yazılanlara göre Windows 7'yi desteklemiyor. Linux'ta gtk tabanlı masaüstlerinde destekleniyor denmiş, ama 3.36.7 gnome-shell'e sahip Fedora 32'de de çalışmadı. Olsun, yakında çalışır.

Olur da bu özelliği kapatmak istersek adres satırına about:config yazdıktan sonra 

media.hardwaremediakeys.enabled = false

yapmamız gerek. Ayrıca bir de timeout özelliğinden bahsedilmiş:

media.mediacontrol.stopcontrol.timer

Bunu etkinleştirdikten ve varsayılan olarak 60 saniyelik bir süre geliyor (onu da media.mediacontrol.stopcontrol.timer.ms ile değiştirebiliyoruz). Firefox'ta çalan medyayı durdurduktan 60 saniye sonra medya kontrol dışına çıkacak.

---

[1] https://docs.google.com/document/d/1c4FivJpvAjjw9Uw-jn7X1UjGOoWkANXOulNyqDWs83w/edit#heading=h.wsp2v2xk20e

Linux'ta standart akışları yönlendirme

Bir komut satırı uygulaması için 3 temel akış (stream) söz konusu:

0: Giriş için stdin, 

1: çıkış için stdout,

2: hata çıktıları için stderr.

Bir uygulamanın konsolda çalıştığı düşünülerek, bazı giriş ve çıkışlarının olduğu varsayılır. stdin olarak isimlendirilen giriş, klavyedir. Program çıktısını stdout'a yani ekrana basar. Olası hata durumlarında ekrana bazı hata mesajları da basılır ama genellikle hata mesajlarının normal stdout çıktısınıdan ayrı olması istendiği için onun akışı ayrıdır, stderr olarak adlandırılır.

stdin yönlendirmesi

Tüm girişin klavyeden değil de, bir programın çıktısından ya da bir dosyadan olması gereken durumlarda kullanılır.

$ head < dosya.txt

Yönlendirme operatörü olarak "<"  kullanıldı.

stdout yönlendirmesi

Genelde bir komutun planlanan tüm çıktılarını başka bir komuta veya dosyaya yönlendirmek için kullanılır.

$ ls -ld */  | wc -l # tüm klasörleri say

$ last -s 2019-05-01 | awk '{print $1}' #tarihten sonra yeniden başlatan kullanıcıları isimleri

$ find . -iname "*.txt" -newermt "5 months ago" -ls > new_txt_files.log # son 5 ayda değiştirilen dosyaların listesini new_txt_files.log'a yaz

Burada > operatörünün yanında boru "|" operatörünün de kullanıldığına dikkat.

stderr yönlendirmesi

3 klasörün içeriklerini bir dosyaya yazdığımızı düşünelim. Ama üçüncü klasör var olmayan bir yolu gösteriyor.

$ ls Belgeler Resimler Filmler > dosya_listesi.txt

Bu komut Belgeler ve Resimler klasörünün çıktısını belirtilen dosya_listesi.txt dosyasına yazarken, Filmler klasorunun var olmadığına dair hatayı sadece ekrana yazar ve dosya_listesi.txt dosyasına bir mesaj yazmaz. Bunun sebebi, hata çıktısının farklı bir kanaldan gönderilmesidir. İki seçeneğimiz var. Ya stderr akışını hata.txt dosyası gibi bir dosyaya yazabilir, ya da hataları da dosya_listesi.txt dosyasına atabiliriz. İlk durum için komudumuz şöyle olabilir:

$ ls Belgeler Resimler Filmler 2> hata.txt 1> dosya_listesi.txt

İkinci durum için komudumuz şöyle olabilirdi:

$ ls Belgeler Resimler Filmler > dosya_listesi.txt 2>&1

Burada sonda yer alan 2 numaralı stderr akışını &1'e yönlendirme bölümünün stdout'un dosya_listesi.txt'ye yönlendirmesi (> dosya_listesi.tx) bölümünden sonra olması önemli. Eğer sıra değişirse sadede stdout dosyaya yazılır (çünkü stderr > stdout yönlendirmesi sırasında stdout dosyaya yönlendirilmemiş olur)

Alternatif olarak bash'e özel &> kısaltması (2>&1 ile aynı anlama gelir) kullanılabilir:

$  ls Belgeler Resimler Filmler &> dosya_listesi.txt

---

[1] https://linuxize.com/post/bash-redirect-stderr-stdout/

[2] https://linuxhandbook.com/redirection-linux/

[3] https://www.guru99.com/linux-redirection.html

[4] https://www.putorius.net/linux-io-file-descriptors-and-redirection.html

[5] https://linuxconfig.org/bash-scripting-tutorial-for-beginners

Linux, static route ve netplan

Ubuntu 18.04 ve sonrası artık route tablosuna giriş eklemek için netplan kullanıyor.

Bir örnek üzerinden gidelim. Yerel ağımızdaki IP aralığı 192.168.1.0/24 olsun. Bir de uzak ofisimiz var, onun da IP aralığı 192.168.2.0/24. Uzak ofisteki kullanıcıların merkeze ulaşması için kurulan router'ın IP adresi de 192.168.2.101 olsun.

Bu durumda iletişimin sağlanabilmesi için, örneğin, uzak ofisteki bir ubuntu makinenin üzerinde

$ sudo ip route add 192.168.1.0/24 via 192.168.2.101 dev ens32

gibi bir yönlendirme girişi yapmak gerek. Ancak bu kalıcı olmayacak. Bir sonraki yeniden başlatmada da geçerli olmasını sağlayabilmek için /etc/netplan altındaki dosyayı düzenlememiz gerekecek. Bu klasörde ismi standart olmayan bir dosya vardır, kast edilen dosya bu. Elle IP adresi ataması yapılmış bir bilgisayar için bu dosyanın içeriği şu şekilde olabilir:

network:
    ethernets:
        ens32:
            addresses:
            - 192.168.2.7/24
            dhcp4: false
            gateway4: 192.168.2.1
            nameservers:
                addresses:
                - 192.168.2.2

Buraya, gördüğüm kadarıyla gateway4'ün hemen altına, şu satırları girmek gerek:

- to: 192.168.1.0/24
  via: 192.168.2.101

Yani tam içerik şöyle olacak:

network:
    ethernets:
        ens32:
            addresses:
            - 192.168.2.7/24
            dhcp4: false
            gateway4: 192.168.2.1
             - to: 192.168.1.0/24
               via: 192.168.2.101
            nameservers:
                addresses:
                - 192.168.2.2

Bu şekilde işlem tamam.

---

2020-12-28 ek: Netplan yaml dosyasındaki hatalardan dolayı yapılandırma uygulanmazsa bunun kaydını görmek için

$ journalctl -b -g netplan # NETPLAN (büyük harflerle) de olabilir

kullanılabilir. Ayrıca yaml dosyasındaki hataları görebilmek için netplan komutu ile birlikte aşağıdaki parametreler kullanılabilir:

# netplan try # yaml dosyasındaki ayarları uygula, hata varsa mevcut duruma geri dön

# netplan apply # yaml dosyasındaki ayarları uygula

# netplan ip leases ens33 # arayüz üzerindeki DHCP atamalarını görüntüle

Bunların haricinde üzerinde çalıştığımız sistem IP adresini bir DHCP sunucudan almışsa bu sunucuyu bulmak için

$ journalctl -b -g DHCP # anahtar kelime konusunda yaratıcı olmak gerekebilir

Veya çoğu dağıtğımda /var/lib/dhclient/dhclient.leases gibi bir dosyanın içeriğini inceleyebiliriz:

$ cat /var/lib/dhclient/dhclient.leases

Bunlar işimizi görmezse UDP 68 üzerinden gerçekleşen ağdaki DHCP trafiğine göz atmak istersek:

# tcpdump -i eth0 -nev udp port 68

ve hatta ağdaki DHCP sunucuyu bulabilmek için bir dhcp-discover paketi göndermek için

# nmap --script broadcast-dhcp-discover -e eth0

DHCP'nin mevcut atamasını serbest bırakıp yeniden istekte bulunmak için

# dhclient -r

Şu anda sistemin kullandığı DNS sunucuyu görmek için

# resolvectl dns

Gerekli durumda ağ hizmetlerini tekrar başlatmak için

$ sudo systemctl restart network-manager

---

https://netplan.io/examples/

WannaCry

2016 yılında Shadow Brokers adında bir hacker grubu, NSA tarafından kullanıldığı iddia edilen bazı araçları yayınladı. Bu araçların arasında birçok işletim sistemine ait sıfırıncı gün (zero day) açıklarından faydalanan bazı "faydalı" programlar vardı. Söylenene göre NSA, bu araçların kendilerine ait olduğun yalanlamadı. NSA'in bu araçları kullanarak dünyadaki bütün bilgisayarlar, mobil cihazlar ve hatta televizyonlara girebildiği, hedeflediği kişileri izleyebildiği ve bilgi topladığı iddia edildi.

Yayınlanan araçların içinde dikkat çeken bir araç olan EternalBlue, SMBv1 protokolündeki bir açıktan faydalanıyordu. 2017 yılında bu açığı kullanarak WannaCry kötücül (malicious) yazılımı dünya çapında yüzbinlerce bilgisayara bulaştı. Dosyalar şifrelendi, sistemler çalışmaz hale geldi. Şifrelenen verilerin tekrar ulaşılabilir olması için fidye ödenmesi istendi. Bazıları fidye öderken diğerleri verilerini kaybetti. Bankacılık, sağlık ve ulaşım sektöründe büyük aksaklıklar yaşandı. Sonrasında NotPetya adındaki bir kötücül yazılım da EternalBlue'yu kullandı. Sonradan bu araçların NSA tarafından orta doğudaki bankacılık sistemleri üzerinde kullandığına dair bazı bilgiler yayınlandı [7].

İlginçtir, Microsoft NSA'i sözkonusu sıfırıncı gün açıklarını 5 yıldır kullandığı ve bildirmediği için suçladı. Ya da biz öyle anladık. Sonrasında bu açıklar yayınlanan bazı yamalarla kapatıldı [8]. O günlerden sonra SMBv1 kullanımı önerilmedi. Ama olanlar olmuştu.

O dönemde Shadow Brokers'ın yayınladığı araçlardan bazıları:

• EternalBlue: SMB protokolündeki bir zafiyeti hedef alan bir araç
  
• EternalChampion: SMB protokolünde EternalBlue'dan farklı bir zafiyeti hedef alan bir araç
  
• EternalRomance: Bu da SMBv1 protokolündeki bir zafiyeti hedef alan bir araç
  
• EternalSynergy: Çok ilginç, bu da SMB protokolündeki bir açığı kullanıyor
  
• DoublePulsar: Sistemlerde arka kapı oluşturmaya yarayan bir araç
  
• ExplodingCan: IIS'i hedef alan bir araç
  
• EnglishmanDentist: Microsoft Exchange Server'ı hedef alan bir araç
  
• EsteemAudit: Eski Windows sürümlerindeki RDP protokolünü hedef alan bir araç
• EducatedScholar: Oracle veritabanı sunucularını hedef alan bir araç
• ErraticGopher: Belirli Windows sürümlerindeki Telnet protokolünü hedef alan bir araç
  

Mart 2017 gibi Wikileaks'te Vault 7 adında bu sefer CIA'e ait olduğu iddia edilen başka diğer araçlar (Weeping Angel, Marble Framework gibi) yayınlandı. Bu araçları daha sonra başkaca siber hareketlerin bir parçası olarak görmedik, şükür.

---

[1] https://news.slashdot.org/story/16/10/20/1926222/prosecutors-say-contractor-stole-50-terabytes-of-nsa-data

[2] https://money.cnn.com/2017/04/14/technology/windows-exploits-shadow-brokers/index.html

[3] https://www.wired.com/2016/08/shadow-brokers-mess-happens-nsa-hoards-zero-days/ 

[4] https://www.wired.com/story/eternalblue-leaked-nsa-spy-tool-hacked-world/ 

[5] https://yro.slashdot.org/story/17/04/17/1416228/microsoft-says-previous-windows-patches-fixed-newly-leaked-nsa-exploits 

[6] https://www.wired.com/2017/05/ransomware-meltdown-experts-warned/

[7] https://www.wired.com/2017/04/major-leak-suggests-nsa-deep-middle-east-banking-system/ 

[8] https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/shadow-brokers-leaks-hacking-tools-what-it-means-for-enterprises 

Reklamlar, reklam engelleyiciler ve paranın etiğe etkisi

İlk başta internet reklamları vardı. Sonra reklam engelleyiciler geldi. Bir tarafta ürünlerini satmak için reklam bütçesi ayıran firmalar, diğer yanda da internette reklamlar aracılığıyla ücretsiz sunulan hizmetleri kullanan ama reklam görmek istemeyen kullanıcılar. Evet, ortada bir dengesizlik var. Ama dengesizliğin ilk çıktığı yerin reklam aracı kuruluşları olduğunu düşünüyorum.

Yeni okuduğum bir habere göre reklamlarının hedef kitlelere ulaşmadığını gören büyük reklam verici firmalar çözümü Adblock'a gizli gizli para yedirmekte bulmuşlar. "Kabul edilebilir reklamlar" adı altında "bazı" reklamlar artık kullanıcılar adına "beyazlisteye" alınmaya başlanmış. Amerikalı senatör Ron Wyden da bu beyazlisteyi inceleme konusunu gündeme getirmiş. Perdeler arkasında neler oluyor...

Windows'da stderr akışını yönlendirme

Konsolda çalışan uygulamalar için 3 temel akış vardır:

1. Standart Giriş (stdin)
2. Standart Çıkış (stdoout)
3. Standart Hata (stderr)

Bir program standart bilgilendirmesini stdout'a yapar. Microsoft'un örneği üzerinden gidelim. Eğer olmayan bir dosyayı dir ile listelemek ve çıktısını bir dosyaya yazmak istersek:

C:\> dir abc.def > dosya.txt

File Not Found

hala "File Not Found" hatasını ekranda görürüz. Üstelik bu çıktı dosya.txt'ye de yazılmaz. Çünkü dosyaya yazılan kısım stdout'a gönderilen, "File Not Found" ise stderr'a gönderilen bilgidir.

Bu durumda "File Not Found" mesajını hata.txt dosyasına, geri kalan tüm stdout'ları da dosya.txt dosyasına göndermeyi seçebiliriz:

C:\> dir abc.def 2>hata.txt > dosya.txt

Ya da hataları görmek istemiyorsak stderr'u nul'a yönlendirebiliriz. Dikkat, Windows'da nul tek "l" ile yazılır.

C:\> dir abc.def 2>nul > dosya.txt

Bunlar Linux'ta, Windows komut satırında (cmd.exe) ve Powershell'de de geçerli.

Linux ve Powershell'de geçerli olup da Windows komut satırında geçerli olmayan stderr'un stdout'a yönlendirilmesi. Bunu Linux ve Powershell'de şu şekilde yapabiliriz:

C:\> dir abc.def 2>&1

ya da linux'ta

 $ ls abc.def 2>&1

Bunun sonucunda olmayan bir dosyayı listeleme girişimimizde oluşturulan tüm çıktı stdout'a gitmiş olur. Bunu da toplu olarak bir dosyaya yazabiliriz:

C:\> dir abc.def 2>&1 > dosya.txt

Ama bu iş Windows komut satırında olmadı.

Şu sitede belirtilene göre hem stdout hem stderr'u aynı dosyaya yazmak için bir sıra değişikliği yapmak gerek:

C:\> dir abc.def > dosya.txt 2>&1

Bu durumda şöyle bir genelleme yapılabilir; çıktısı ile ilgilendiğimiz komut sonrasında önce stdout'u yönlendireceğimiz komut yer almalı. Stderr'un yönlendirmesi sonra gelmeli.

Tüm bunlar nerden aklıma geldi; ffprob'u kullanırken üretilen çıktıların tümü stderr'a gönderiliyor; garip bir şekilde. Bunları bir dosyaya yazdıramadım. Ama stderr yönlendirmesi başarılı oldu.

[1]'e göre bir de console çıktımız varmış.

[2]'ye göre powershell 7'de daha da fazlası varmış.

---

[1] https://www.robvanderwoude.com/battech_redirection.php

[2] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_redirection?view=powershell-7