Truenas Scale obsługuje kontenery Dockera używając Kubernetes. Czasem jednak potrzebujemy uruchomić kontener poza Kubernates np. przy budowaniu własnego obrazu. Tutaj jednak pojawia się problem, gdyż domyślnie kontenery uruchamiane przez Dockera nie mają dostępu do internetu, aby rozwiązać ten problem musimy wskazać sieć Dockera, którą chcemy użyć np:
$ docker build --network=host --tag=mojobraz . Często możemy zaobserwować, że czas dostępu do serwerów oceny filtrów jest bardzo długi i mamy problemy z dostępem do stron internetowych. Czas ten możemy sprawdzić w fortigate System > FortiGuard tabelka FortiGuard Filter Rating Servers.
Powodem tego może być, że domyślnie Fotigate korzysta z serwera Anycast. Jednym z rozwiązań może być wyłączenie anycast i pobranie serwerów unicat np. z adresu 208.91.112.220
config system fortiguard
set fortiguard-anycast disable
set protocol udp
set port 8888
set sdns-server-ip 208.91.112.220
endJeżeli chcemy się dostać do GPIO za pomocą Python i biblioteki RPi.GPIO, jako zwykły użytkownik, może pokazać się nam błąd „RuntimeError: Not running on a RPi!”. Ten błąd wynika z braku uprawnień do /dev/gpiomem.
# dodajemy użytkownika na którym pracujemy do grupy dialout
$ sudo usermod -aG dialout tomeks
# ustawiamy na stałe uprawnienia do /dev/gpiomem dla grupy dialout
sudo nano /etc/udev/rules.d/99-gpiomem.rules
KERNEL=="gpiomem", OWNER="root", GROUP="dialout"
# uruchamiamy ponownie
$ sudo reboot$ diagnose debug reset #reset wszystkich wcześniejszych ustawień debug
$ diagnose debug enable #włączenie debug
$ diagnose debug flow filter clear #czyszczenie filtrów przepływów
$ diagnose debug flow filter addr 192.168.128.100 #ustawienie śledzonego ip
$ diagnose debug flow filter proto 1 #id protokołu.Tutaj ICMP
$ diagnose debug flow show fun enable #włącz pokazywanie funkcji
$ diagnose debug flow show iprope enable #włącz komunikaty śladu dotyczące iprope
$ diagnose debug flow trace start 20 #rozpoczęcie śledzenia 20 sesji
id=20085 trace_id=126 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 192.168.100.99:1->192.168.128.100:2048) from internal5. type=8, code=0, id=1, seq=224."
id=20085 trace_id=126 func=init_ip_session_common line=5955 msg="allocate a new session-00657adf"
id=20085 trace_id=126 func=rpdb_srv_match_input line=1030 msg="Match policy routing id=2141519874: to 192.168.128.100 via ifindex-40"
id=20085 trace_id=126 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-XX.XX.XX.XX via IPSEC"
id=20085 trace_id=126 func=fw_forward_handler line=869 msg="Allowed by Policy-1:"
id=20085 trace_id=126 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface IPSEC"
id=20085 trace_id=126 func=_do_ipsecdev_hard_start_xmit line=229 msg="output to IPSec tunnel IPSEC"
id=20085 trace_id=126 func=esp_output4 line=867 msg="IPsec encrypt/auth"
id=20085 trace_id=126 func=ipsec_output_finish line=546 msg="send to XX.XX.XX.XX via wan2"
$ diagnose debug flow trace stop #zatrzymanie
$ diagnose debug disable #wyłączenie debug
Lista procesów.
# diagnose sys top
lub wyszukanie konkretnego procesu np proxyd
# diag sys process pidof proxydUbicie procesu
# diagnose sys kill 11 <process_id>
lub
# fnsysctl killall <process name>
np
# fnsysctl killall proxydDIRB wyszukuje istniejące obiekty sieciowe. Działa poprzez uruchomienie ataku słownikowego na serwer sieciowy i analizę odpowiedzi. Wraz z dirb instalowany jest zestaw wstępnie skonfigurowanych list słownikowych pomocnych w skanowaniu. Słowniki znajdują się w katalogu /usr/share/wordlists/dirb/. Możemy skorzystać z innych otwarto źródłowych słowników np: SecList
DIRB jest pomocny w audycie aplikacji internetowych podczas testów bezpieczeństwa wykorzystujących „Fuzzing”. Fuzzing to technika testowania oprogramowania, w której wysyłamy do programu różne losowe, prawidłowe i nieprawidłowe dane, następnie obserwujemy działanie programu.
Instalacja
$ sudo apt install dirbPrzykład użycia
$ dirb https://adres.strony/ /usr/share/wordlists/dirb/common.txt
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Sat Dec 4 20:30:41 2021
URL_BASE: https://adres.strony/
WORDLIST_FILES: /usr/share/wordlists/dirb/small.txt
-----------------
GENERATED WORDS: 959
---- Scanning URL: https://adres.strony/ ----
+ https://adres.strony/0 (CODE:301|SIZE:0)
+ https://adres.strony/admin (CODE:302|SIZE:0)
Tutaj znalazł 2 obiekty „0” i „admin”
Systemd umożliwia zarządzania usługami przez użytkownika.
Aby konto mogło korzystać z usług systemd bez konieczności logowania musimy włączyć funkcję „linger”
$ loginctl enable-linger nazwa_użytkownikaLogujemy się na użytkownika i w katalogu domowym tworzymy katalog i plik usługi. Przy konfiguracji nie podajemy User w sekcji [Service]
$ mkdir -p ~/.config/systemd/user/
$ vi ~/.config/systemd/user/myapp.service
[Unit]
Description=My demo application
[Service]
ExecStart=plikUslugi
WorkingDirectory=/home/myapp/html
[Install]
WantedBy=default.targetNajpierw musisz przeładować systemd, aby mógł pobrać plik jednostki.
$ systemctl --user daemon-reloadUruchamiamy usługę i włączamy aby uruchamiała się przy starcie sytemu
$ systemctl --user start myapp.service
$ systemctl --user enable myapp.serviceDomyślnie do autoryzacji użytkownika w połączeniu ssh wykorzystujemy hasło. Znacznym ułatwieniem jest wygenerowanie pary kluczy asymetrycznych po stronie klienta i zainstalowanie klucza publicznego na serwerze ssh z którym chcemy się łączyć.
Generowanie kluczy rsa na komputerze kliencie:
$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub
...Przesłanie klucza publicznego ~/.ssh/id_rsa.pub na serwer ssh, z którym będziemy się łączyć:
$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@sshserverTeraz już możemy zestawić połączenie z ssh bez hasła.
$ ssh user@sshserverW czasie przesyłania klucza, program poprosi nas o podanie hasła do konta na serwerze ssh.
Serwer może nie być skonfigurowany do akceptowania uwierzytelniania klucza publicznego. Upewnij się, że /etc/ssh/sshd_config na serwerze zawiera PubkeyAuthentication yes. Pamiętaj o ponownym uruchomieniu procesu sshd na serwerze.
Często podłączenie GNS3 do sieci fizycznej z użyciem komponentu Cloud może sprawić duże problemy.
Jeżeli w naszym przypadku występuje problem, możemy dodać do GNS3 VM dodatkową kartę sieciową ustawioną w trybie Bridged.
Teraz przy wstawianiu komponentu Cloud do projektu wybieramy jako serwer maszynę GNS3 VM
Podłączając komponent wirtualnym kablem, wybieramy dodaną kartę sieciową, która pracuje w trybie Bridged na GNS3 VM.
Starsze wersje iDrac KVM wykorzystują SSLv3, który uznawany jest za niebezpieczny. Aby uruchomić zdalny dostęp KVM musi na czas połączenia uznać SSLv3 jako bezpieczny.
W katalogu instalacji javy w pliku lib\security\java.security komentujemy linijkę zawierającą jdk.tls.disabledAlgorithms=SSLv3