port durumu inceleme

Tüm ICMP trafiği açık olsa bile ping'in yeterli olmadığı durumlar vardır.

Uzak sunucuda çalışan bir hizmetin açık portunun cevap verip vermediğini inceleme ihtiyacı olur; 80 numaralı HTTP portuna erişebiliyor muyum, NTP sunucusunun 123 UDP portu dinlemede mi gibi.

Powershell dünyasında kısmen TCP için

PS> Test-NetConnection -ComputerName uzakpc -Port 80

gibi bir yöntem var.

2023-11-20 ek: daha hızlı bir yöntem

PS> (New-Object Net.Sockets.TcpClient).Connect("192.168.1.1",80)

hata vermezse başarılıdır. Başarısız durumda hata verir.

Yine TCP için Sysinternals'ın psping'i kullanılabilir:

PS> psping uzakpc:80

Ama UDP için benzer bir araç bilmiyordum. Linux'ta netcat (nc) için şöyle bir kullanım buldum:

$ nc -z -u -v time.windows.com 123

Connection to time.windows.com 123 port [udp/ntp] succeeded!

burada

-z : zero IO (sadece bağlantı durumunu bildir, gereksiz veri alışverişi yapma)

-u : UDP kullan

-v : verbose (ayrıntılı çıktı göster)

Windows'da ise gerek WSL gerekse nmap ile gelen nc klonu ncat ile de benzer kullanım mümkün. UDP için

PS> ncat -vuz time.windows.com 123

Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connected to 40.119.148.38:123.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.04 seconds.

veya TCP için

PS> ncat -vt uzakpc 80

Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Connected to xx.xx.xx.xx:80.

ncat, TCP için -z (zero IO) parametresini kabul etmedi, protokolün doğası gereği. Yukarıdaki komuttan sonra bağlantı açık kalır, web snuucu GET, POST gibi komutlardan birini bekler. Örneğin Ctrl+C ile çıkmadan aşağıdaki gibi bir komut yazılarak varsayılan açılış sayfası istenebilir:

GET / HTTP/1.1

Benzer ihtiyacı olan powershell severler, kendi cmdlet'lerini de yapmışlar [1].

Bu arada 123/udp portuna bağlanabiliyor olmak, çalışan bir NTP hizmeti olduğu anlamına gelmez, sadece ilgili sunucunun NTP portuna bağlanabildiğimizi gösterir. Aynı şekilde 80/tcp portuna bağlanmak web sunucunun tam olarak istediğimiz şekilde çalıştığını göstermez, sadece bu portunu dinleyen bir hizmetin aktif olduğunu gösterir.

---

[1] https://cloudbrothers.info/en/test-udp-connection-powershell/

Karanlık tema

Blog'un görseline uzun zamandır gereken önemi veremediğimin farkındaydım. Nihayet o gün bugünmüş. Karanlık temamın güzel olduğunu düşünüyorum. "Nihayet, gecenin bir vakti blog yazarken beyaz ışığa bakmayacağım" demek isterdim, ama düzenleme sayfasının teması değişmiyormuş. Olsun, bu da bir şey.

pktmon

Linux sistemlerde mümkündü, ama Windows'da olduğunu yeni öğrendim. Uzaktaki bir sistemin yakalanan paketleri kaydetmesini (Wireshark veya tcpdump gibi) nasıl sağlayabilirim?

Şu videoda belirtildiği gibi pktmon kullanarak:

pktmon start --capture

ile başlanan yakalama işlemi, mevcut klasördeki pktmon.etl dosyasına kaydediliyor. Bu dosyayı açmak için bir sürü yöntem vardır eminim, ama Wireshark ile açmak için önce bu dosyayı pcapng formatına dönüştürmek gerek. Bunu da

pktmon etl2pcap pktmon.etl

diyerek yapabiliyoruz. Bundan sonrası Wireshark işleri. Filtreler ekleme için şu ve bu sayfalar faydalı olabilir. Örneğin --capture ile yakalamaya başlamadan önce hedefimizi daraltmak ve yakalanan dosyayı küçültmek için şu şekilde filtreler eklenebilir:

pktmon filter add -i 1.1.1.1 -t icmp

Bu satır ile 1.1.1.1 adresine giden ve bu adresten gelen ICMP paketleri yakalanır.

pktmon filter add -p 53

Yukarıdaki satır da sadece 53 portu (DNS) trafiğini yakalar.

Yakalamayı sonlandırmak için ise stop komutu kullanılır

pktmon stop

ssh-rsa algorithm is disabled

Linux sunucularda oturum açmak için kullandığım görece "yeni" bir rsa anahtarım vardı. Yeni kurulum yaptığım bir sunucuya da bu anahtarı aktarıp ssh ile oturum açmaya çalıştığımda kabul etmedi, loglarda

sshd[xxxxx]: main: sshd: ssh-rsa algorithm is disabled

gibi bir satır gördüm. Niye acaba ssh-rsa devre dışı bırakılmış olabilir diye bir arama yapmak yerine bunu ChatGPT'ye sormak istedim:

Özetle ssh-rsa, SHA1 hash işlevlerini kullandığı için, SHA1'in ise artık güvensiz kabul edildiğinden [1] dolayı, devre dışı geliyormuş. Bu konuda ilginç görüşler [2] de var ama camia güvensiz diyorsa güvensizdir.

SHA1'in güvensiz kabul edildiğini biliyordum, ama RSA'nın SHA1 kullandığını bilmiyordum. Son 1 yılda kurulmuş bir sunucu (Debian) üzerinde oluşturduğum ssh anahtarımın da ssh-rsa olduğunu öğrenince şaşırdım.

İki seçeneğim var; ya sunucuda (güvenlik uyarılarını göz ardı ederek) ssh-rsa desteğini etkinleştireceğim, ya da ssh anahtarımı sha512 desteği olacak şekilde yenileyeceğim. İlk yöntemi denemek istemesem de serverfault.com'da ve redhat.com'da şu şekilde bir yöntem belirtilmiş:

# update-crypto-policies --set DEFAULT:SHA1

Ayrıca stackexchange.com'da da bir yöntem buldum, ama RockyLinux'ta işe yaramadı.

Gelelim önerilen yönteme. ssh-keygen'in sha512 kullanmasını söyleyen bir parametre yok. Ama çeşitli kaynaklardan [3,4] bulduğum yöntem ssh-keygen'e -t ile anahtar tipini ecdsa olarak belirtmek ve bit uzunluğunu 521 (evet, ilginç) seçmek.

$  ssh-keygen -t ecdsa -b 521

man ssh-keygen'de parametreler hakkında şu bilgiler var:

-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
             Specifies the type of key to create.  The possible values are “dsa”, “ecdsa”, “ecdsa-sk”, “ed25519”, “ed25519-sk”, or “rsa”.

-b bits
             Specifies the number of bits in the key to create.  For RSA keys, the minimum size is 1024 bits and the default is 3072 bits.  Gener‐
             ally, 3072 bits is considered sufficient.  DSA keys must be exactly 1024 bits as specified by FIPS 186-2.  For ECDSA keys, the -b
             flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits.  Attempting to use bit
             lengths other than these three values for ECDSA keys will fail.  ECDSA-SK, Ed25519 and Ed25519-SK keys have a fixed length and the -b
             flag will be ignored.

Bir genel anahtarın içine bakarak ne tür bir algoritma kullandığını görebiliriz:

$ cat id_ecdsa.pub

ecdsa-sha2-nistp521  ...

---

[1] https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-completely-unsafe.html

[2] https://www.quora.com/Does-SHA-1s-insecurity-have-any-effect-on-Git

[3] https://cloud.ibm.com/docs/hp-virtual-servers?topic=hp-virtual-servers-generate_ssh 

[4] https://www.ssh.com/academy/ssh/keygen#choosing-an-algorithm-and-key-size

 

pacman.log

Uzun bir süredir Manjaro kurulu olan bir bilgisayarım var. Diskini değiştirdim, diskte yer azaldı, temizlik yaptım, ama pacman.log dosyasını hiç temizlemedim. 4 seneden fazla bir zamandır kullanıyormuşum:

$ head -5 /var/log/pacman.log

İlk satırdaki tarih ilk güncelleme yaptığım tarih.

5 farklı sürüm LTS çekirdek kurmuşum:

$ grep -E 'installed linux[[:digit:]]{2,3}[[:blank:]]' /var/log/pacman.log | wc -l

5

grep komutuna özgü [[:digit:]] ve [[:blank:]] zırvaları ile uğraşmamak için

$ grep -E 'installed linux[0-9]{2,3} ' /var/log/pacman.log | wc -l

de kullanabiliriz. Ama + ve * gibi nicelik belirten operatörler için yine -en azından grep kullanırken- [[:digit:]] ve [[:blank:]] gibi işleçlere ihtiyaç var.

Bütün çekirdek güncellemeleri bu kadar değil. Güncellemeler 248 kez olmuş:

$ grep -E 'upgraded linux[[:digit:]]{2,3}[[:blank:]]' /var/log/pacman.log | wc -l

248

80 kez pacman ile kurulum yapmışım:

$ grep "Running 'pacman -S " /var/log/pacman.log | grep -v "pacman -S -" | wc -l

80

Kaç kez "büyük" sistem güncellemesi yaptığımı bulamadım. Ama sanıyorum her güncelleme öncesinde manjaro-keyring yükseltiliyor. Buradan belki şu komut ile bir yerlere varsabilir miyiz

$ grep "upgraded manjaro-keyring" /var/log/pacman.log

Ek 2024-02-25: Manjaro sistem sürümünü değiştiren güncellemelerin loglarda nasıl tespit edilebileceğini yine chatGPT sayesinde buldum:

$ grep "[ALPM] upgraded manjaro-release" /var/log/pacman.log | wc -l
75 

Ayrıca pacman.log'larından şunları da öğrendim. Eğer pacman -Syu yapıyorsam loglarda
[PACMAN] Running 'pacman -Syu'
satırı geçiyor. Eğer pamac update yapıyorsam loglarda
[PAMAC] synchronizing package lists
geçiyor. Eğer grafik arayüzden octopi kullanıyorsam da loglarda
[PACMAN] Running '/usr/bin/pacman -S --noconfirm
geçiyor. Bunların sonucunda pacman.log dosyam 3,5 MB civarında.

Uzaktan winget kurulumu

Etki alanındaki makinelerde bile winget varsayılan olarak kurulu gelmiyor, şu an için. Kurmak için şu adresten kurulum paketini indirmek gerek.Uzaktan kurulum yapacağım için Microsoft Store'dan indirmek bir seçenek değil.

Kurulum paketimizin adı Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle gibi birşey olacak. Bunu hedef makinemizin D:\ sürücüsünün köküne koyduğumuzu varsayalım. Daha sonra bir uzak powershell bağlantısı gerçekleştirmemiz lazım.

PS> etsn uzakpc

Bu aşamadan sonra varsayılan olarak uzaktaki PC'nin C:\Users\<kullaniciadi>\Documents gibi bir konumunda oturumumuz başlayacak. Önce

[uzakpc] C:\Users\metin\Documents\> cd D:

gibi bir komutla kurulum dosyamızın olduğu konuma geçiş yaptım. Daha sonra da Add-AppxPackage ile kurulumu başlattım.

[uzakpc] D:\Add-AppxPackage -Path .\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle

Bu komut hiçbir mesaj göstermeden tamamlandı. Sonrasında

[uzakpc] D:\> winget list

ile algılanan paketleri sorgulamak istediğimde önce anlaşılmaz birkaç bozuk satırdan sonra şöyle bir  hata verdi:

The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

Do you agree to all the source agreements terms?
[Y] Yes  [N] No: An unexpected error occurred while executing the command:
0x8a150042 : Error reading input in prompt

Ama Y veya N'ye basmama izin vermeden çıktı. Uzaktan bu prompt sorununu nasıl halledebilirim diye winget'in parametrelerine bakarken

 --disable-interactivity   Disable interactive prompts

parametresini farkettim. winget'i bu parametre ile çalıştırmayı denediğimde de asıl sorun ortaya çıktı:

[uzakpc] D:\winget list --disable-interactivity

The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

One or more of the source agreements were not agreed to. Operation cancelled. Please accept the source agreements or remove the corresponding sources. 

Bu konu ile yaptığım aramada da şu sayfada winget'in yardımında (/? ile ulaşılan) listelenmeyen iki parametersini buldum:

--accept-package-agreements

--accept-source-agreements

Benim durumumda bu sanki "source agreements" ile ilgili görünüyordu. Bu sebeple ikinci paremetre ile şansımı denedim:

[uzakpc] D:\> winget list --accept-source-agreements

ve sonuca ulaştım.

2023-09-01 Ek: Şu videoda indirmeden doğrudan kurmayı seçmiş. Bir ara denemek lazım:

PS> Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe

Oldu.