Pobieramy z SysInternals program PsTools i z tego pakietu uruchamiamy 'psexec’ z uprawnieniami administratora.
psexec -s -i cmd.exeTeraz w nowej konsoli możemy uruchomić dowolny program w kontekście uprzywilejowanego użytkownika SYSTEM. Dzięki temu możemy np. przetestować skrypt, który ma być uruchomiony z polityki GPO na wszystkich komputerach w domenie.
W Kali linux uruchamiamy polecenie:
certipy-ad find -stdout -vulnerable -dc-ip <ip domain controller> -target <domena windows> -u <domain user>domain user to zwykły użytkownik domeny bez praw admina
W odpowiedzi na dole ekranu w sekcji „[!] Vulnerabilities” zobaczymy podatności naszego serwera ADCS np:
ESC8 : Web Enrollment is enabled and Request Disposition is set to Issue
A w sekcji „Certificate Templates” podatne szablony certfikatów, jeżeli istnieją.
Przy próbie połączenia za pomocą FortiClient z VPN w Ubuntu 24.04 wyświetla się komunikat „config DNS failed”.
Problem wydaje się występować jeżeli w systemie mamy zainstalowane interfejsy sieciowe z Vmware Workstion lub Docker. Aby rozwiązać problem, należy w konfiguracji wykluczyć te interfejsy z zarządzania przez NetworkManager.
Edytujemy plik /etc/NetworkManager/NetworkManager.conf i dodajemy interfejsy, które chcemy wykluczyć:
$ sudo nano /etc/NetworkManager/NetworkManager.conf
[keyfile]
unmanaged-devices=interface-name:docker0;interface-name:br-*;interface-name:vmnet*W mim przypadku docker0 i br-* to interfejsy Docker a vmnet* to maska interfejsów Vmware
Restarujemy NetworkManager i Docker jeżeli go używamy:
sudo systemctl restart NetworkManager
sudo systemctl restart dockerChcemy usunąć snapshoty, które w nazwie mają „test” z sierpnia 2024
Listujemy, które snapshoty zostaną usunięte:
# zfs list -t snapshot -H -o name | grep "test.*2024-08" | xargs -n1 echoUsuwamy
# zfs list -t snapshot -H -o name | grep "test.*2024-08" | xargs -n1 zfs destroyGdy nasza domena nie jest używana do rozsyłania poczty, możemy dodać do dnsu wpisy, które będa utrudniać przyjmowanie poczty z naszej domeny przez inne serwery.
SPF – nie zgadzamy się na wysyłanie poczty z żadnego adresu IP
nasza.domena.pl TXT v=spf1 -allDMARC – Informujemy odbiorcze serwery poczty, aby w przypadku nie zgodności polityk DMARC odrzucały maile
_dmarc.nasza.domena.pl TXT v=DMARC1;p=reject;Wygasłe certyfikaty powinny się odnowić przy ponownym uruchomieniu k3s:
# systemctl restart k3sJeżeli certyfikaty się nie odnowią i widzimy komunikat:
# kubectl get nodes
Unable to connect to the server: x509: certificate has expired or is not yet validMożemy wymusić wygenerowanie nowych.
Zabezpieczamy katalog z dotychczasowymi sekretami TLS
# tar -czvf /var/lib/rancher/k3s/server/apphost-cert.tar.gz /var/lib/rancher/k3s/server/tlsUsuwamy plik
# rm /var/lib/rancher/k3s/server/tls/dynamic-cert.jsonUsuwamy zbuforowany certyfikat z sekretów kubernetes
# kubectl --insecure-skip-tls-verify=true delete secret -n kube-system k3s-servingUruchamiamy ponownie usługę K3s, aby odnowić certyfikaty
# systemctl restart k3sUsługa GoogleUpdater często zmiania swoją nazwę a Zabbix nas o tym informuje. Zmienimy ustawienia Zabbixa aby nie monitorował tej usługi.
Możemy stworzyć configmapę na podstawie dowolnego pliku. W naszym przypadku bedzie to plik appsettings.json.
$ kubectl create configmap ares-api-config --from-file=Configuration/appsettings.json -n testTa metoda nie pozwoli nam zaktualizować configmapy bez jej usunięcia z klastra. Aby rozwiązać ten problem możemy najpierw utworzyć na podstawie naszego pliku appsettings.json plik yaml, następnie go zaaplikować. Gdy będziemy chcieli zmienić obiekt configmap w klastrze to powtarzamy ten proces.
$ kubectl create configmap ares-api-config --from-file=Configuration/appsettings.json -n test --dry-run=client -o yaml > configmap.yaml
$ kubectl apply -f configmap.yaml -n testGdy potrzebujemy przetestować przebieg połączenie ssl z serwerem http, poczty lub innym wykorzystującym protokół ssl/tls, możemy spróbować połączyć się z serwerem używając openssl w trybie klienta.
# openssl s_client -connect google.com:443
CONNECTED(00000003)
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = *.google.com
verify return:1
---
Certificate chain
0 s:CN = *.google.com
i:C = US, O = Google Trust Services, CN = WR2
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 3 06:35:38 2024 GMT; NotAfter: Aug 26 06:35:37 2024 GMT
1 s:C = US, O = Google Trust Services, CN = WR2
i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIOTTCCDTWgAwIBAgIQag+0Dl9hY5UKDMPiKzcGqDANBgkqhkiG9w0BAQsFADA7
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMQww
. . . . .W wyniku polecenia zobaczymy cały przebieg połączenia który może ułątwić nam identyfikację problemów z certyfikatami
Gdy chemy sprawdzić start tls smtp do do polecenia dodajemy parametr -starttls smtp lub -starttls ftp
Gdy moniturujemy porty w switch Cisco korzystając z templates „Cisco IOS SNMP” i w pewnym momencie świadomie wyłączamy kabel sieciowy np z portu 1 i nie będziemy chwilowo korzystać z tego portu to Tiger pokazuje nam cały czas błąd „Port down” zaciemniając listę innych problemów
Aby ten alarm się nie pokazywał dodajemy makro do konfiguracji monitorowanego switcha: {$IFCONTROL:"Ethernet1/0/1"} = 0
Macro to wymusi skasowanie błędu.
Gdy alert zostanie usunięty z listy problemów to usuwamy to macro z konfiguracji i w przyszłości gdy ponownie będziemy używać tego portu to Zabbix będzie nas informował o problemach.