FortiGate – Failed to save some changes: Value conflicts with system settings.

Pewnie też mieliście okazję zobaczyć ten komunikat i przyznam szczerze, że jest on trochę irytujący, bo nie da się z tym nic zrobić z poziomu GUI. Trzeba z CLI. Problem jest związany z funkcją Content Disarm and Reconstruction, która jest dostępna tylko w trybie inspekcji Proxy. Rozwiązania są tutaj:

Na początku trzeba stworzyć profil dla protokołów w CLI:

anzena-forti # config firewall profile-protocol-options 
anzena-forti (profile-protocol~ons) # edit nowy
new entry 'nowy' added
anzena-forti (nowy) # config smtp
anzena-forti (smtp) # set options fragmail oversize
anzena-forti (smtp) # end
anzena-forti (nowy) # end
anzena-forti #

Potem taki profil trzeba przypisać do polityk firewalla, w których chcemy używać profilu AntiVirus z włączoną wspomnianą opcją. Należy znaleźć ID i do takiego ID polityki firewalla przypisać opcje protokołów, które właśnie zdefiniowaliśmy. Będąc w Policy & Objects > Firewall Policy i przechodząc do szczegółów wybranej reguły zobaczymy jej szczegóły (i potrzebne ID):

Przypisanie profilu protokołów wygląda dla takiej polityki w ten sposób:

anzena-forti # config firewall policy 
anzena-forti (policy) # edit 13
anzena-forti (13) # set utm-status enable
anzena-forti (13) # set profile-protocol-options nowy 
anzena-forti (13) # end
anzena-forti #

FortiGate i JPK w urzędach

Ten krótki post zostawiam dla pań i panów pracujących w IT, którzy w FG mają problemy z przepuszczeniem ruchu dla wysyłek JPK. Takie coś się wysyła w urzędach gminy i miast (nie wiem jak jest w starostwach powiatowych) i robi to ta aplikacja. Ostatnio siedziałem nad tym problemem z jednym z moich klientów i rozwiązanie jest następujące – na początku należy sobie zadać pytania:

  • Z jakich komputerów owe JPK jest wysyłane?
  • Czy te komputery mają zmienny adres IP?
  • Czy jednym z komputerów do JPK jest laptop? Jeśli tak, używa karty bezprzewodowej w sieci urzędu?

Po ustaleniu tego musimy zrobić politykę, w której przepuszczamy ruch dla konkretnych adresów bez dokładnego filtrowania aplikacji. Dlatego musimy mieć zawsze te same adresy hostów, które te JPK wysyłają. Jeśli mamy do czynienia z laptopem to musimy zrobić w DHCP rezerwację zarówno dla karty przewodowej jak i bezprzewodowej. Na początku warto zacząć od dodania wspomnianych rezerwacji, zrobimy to w ustawieniach interfejsu lokalnego, w IP Address Assignment Rules (możemy wpisać adresy ręcznie lub dodać je z listy adresów, które dostały swoją dzierżawę w DHCP automatycznie):

Potem warto w Device Inventory zapisać urządzenia do listy adresów – można to zrobić ręcznie, ale jeśli na interfejsach mamy włączoną opcję Device Detection to tutaj samo się znajdzie, o tak:

Tutaj tak samo – można takie adresy sobie zdefiniować ręczne w Addresses, klikając w Create New > Address, poniżej przykład definicji takiego komputera. Warto dodać, że tutaj zdefiniowałem adres z końcówką /32 – to oznacza wskazanie na konkretny adres hosta, poza tym określiłem tutaj w Interface interfejs, do którego urządzenie jest podłączone. To oznacza, że ten adres można wykorzystać tylko w politykach dotyczących tego właśnie interfejsu.

Po tym warto stworzyć sobie grupę użytkowników, którzy łączą się do serwerów na wysyłkę JPK. Na na wdrożeniu nazwałem Nadawcy JPK. Wtedy to jest jaśniejsze w konfiguracji. Do tej grupy dodajemy wszystkie komputery, które mają JPK wysyłać.

Takie dodanie obiektów wygląda tak:

Mając to, robimy w taki sam grupę adresów, ale tym razem dla adresów serwerów i one powinny wyglądać tak:

Musimy zrobić takie 4 obiekty z różnymi FQDNami:

  • e-dokumenty.mf.gov.pl
  • mf.gov.pl
  • blob.am5prdstr10a.store.core.windows.net
  • blob.am3prdstr10a.store.core.windows.net

Potem trzeba (nie trzeba, ale warto) zrobić grupę, którą można nazwać np. Serwery JPK i dodać te adresy do grupy. Na końcu trzeba stworzyć politykę, która z interfejsu lokalnego do interfejsu WAN przepuszcza ruch z grupy Nadawcy JPK do grupy Serwery JPK. Jeśli chodzi o porty – puściłem tutaj dowolne porty, bo nie byłem w stanie znaleźć portów, które są wykorzystywane w snifferze. Wydaje mi się, że to były porty HTTP+S, ale gdy stworzyłem taką politykę z tymi portami to nie byłem w stanie wysłać JPK.

Na samym końcu taką politykę powinniśmy mieć zdefiniowaną nad ogólnymi politykami dla użytkowników, na przykład w ten sposób:

I gotowe.

Ustawienie domyślnego startu ze starszej wersji kernela Linux w GRUB

Domyślnie GRUB startuje z 0, czyli wpisu, który jest na samej górze listy. To może być problematyczne, jeśli nasz system się od czasu do czasu aktualizuje, a my z powodu jakiejś aplikacji nie możemy się przenieść na nowszą wersję, na przykład aktualnie Docker nie obsługuje kerneli 5.x, a 4.x owszem. By pozbyć się problemu należy:

  • zawsze odpalać system z tego samego wpisu w GRUB,
  • zapobiec usunięciu starego kernela z systemu.

To pierwsze można osiągnąć poprzez edycję pliku /etc/default/grub. Często nie mamy dostępu do KVMa lub dostęp do niego na serwerach zabiera nam cenny czas, więc możemy sobie wygenerować szybko listę wpisów takim one-linerem:

sed -nre "/submenu|menuentry/s/(.? )'([^']+)'.*/\1 \2/p" < /boot/grub/grub.cfg
menuentry  Ubuntu
submenu  Advanced options for Ubuntu
        menuentry  Ubuntu, with Linux 5.4.0-37-generic
        menuentry  Ubuntu, with Linux 5.4.0-37-generic (recovery mode)
        menuentry  Ubuntu, with Linux 5.4.0-33-generic
        menuentry  Ubuntu, with Linux 5.4.0-33-generic (recovery mode)
        menuentry  Ubuntu, with Linux 4.10.0-42-generic //z tego chcę odpalać system
        menuentry  Ubuntu, with Linux 4.10.0-42-generic (recovery mode)

W takiej sytuacji w /etc/default/grub w zmiennej GRUB_DEFAULT wpisuję wartość:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 4.10.0-42-generic"
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
GRUB_RECORDFAIL_TIMEOUT=0
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1600x900

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Potem wystarczy wykonać sudo update-grub i gotowe. Jeśli nie chce się Wam grzebać w konsoli to jest aplikacja okienkowa, która też robi robotę. Teraz upewnijmy się, że nasz kernel nie zostanie usunięty z systemu. Na początku musimy się zorientować jaka jest nasza wersja kernela (jeśli tego nie widzieliśmy wyżej):

dpkg -l | grep linux-image
ii  linux-image-4.10.0-42-generic         4.10.0-42.46~16.04.1                        amd64        Linux kernel image for version 4.10.0 on 64 bit x86 SMP
rc  linux-image-4.15.0-36-generic         4.15.0-36.39                                amd64        Signed kernel image generic
rc  linux-image-4.15.0-38-generic         4.15.0-38.41                                amd64        Signed kernel image generic
rc  linux-image-4.15.0-39-generic         4.15.0-39.42                                amd64        Signed kernel image generic
rc  linux-image-4.18.0-13-generic         4.18.0-13.14                                amd64        Signed kernel image generic
rc  linux-image-4.18.0-14-generic         4.18.0-14.15                                amd64        Signed kernel image generic
rc  linux-image-4.18.0-15-generic         4.18.0-15.16                                amd64        Signed kernel image generic
ii  linux-image-4.4.0-112-generic         4.4.0-112.135                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-116-generic         4.4.0-116.140                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-119-generic         4.4.0-119.143                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-121-generic         4.4.0-121.145                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-122-generic         4.4.0-122.146                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-124-generic         4.4.0-124.148                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-127-generic         4.4.0-127.153                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-128-generic         4.4.0-128.154                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-130-generic         4.4.0-130.156                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-131-generic         4.4.0-131.157                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-133-generic         4.4.0-133.159                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-134-generic         4.4.0-134.160                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-135-generic         4.4.0-135.161                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-4.4.0-137-generic         4.4.0-137.163                               amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
rc  linux-image-5.0.0-13-generic          5.0.0-13.14                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-15-generic          5.0.0-15.16                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-16-generic          5.0.0-16.17                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-17-generic          5.0.0-17.18                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-19-generic          5.0.0-19.20                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-20-generic          5.0.0-20.21                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-21-generic          5.0.0-21.22                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-23-generic          5.0.0-23.24                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-25-generic          5.0.0-25.26                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-27-generic          5.0.0-27.28                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-29-generic          5.0.0-29.31                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-31-generic          5.0.0-31.33                                 amd64        Signed kernel image generic
rc  linux-image-5.0.0-32-generic          5.0.0-32.34                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-19-generic          5.3.0-19.20                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-22-generic          5.3.0-22.24                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-23-generic          5.3.0-23.25                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-24-generic          5.3.0-24.26                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-26-generic          5.3.0-26.28                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-29-generic          5.3.0-29.31                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-40-generic          5.3.0-40.32                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-42-generic          5.3.0-42.34                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-45-generic          5.3.0-45.37                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-46-generic          5.3.0-46.38                                 amd64        Signed kernel image generic
rc  linux-image-5.3.0-51-generic          5.3.0-51.44                                 amd64        Signed kernel image generic
rc  linux-image-5.4.0-29-generic          5.4.0-29.33                                 amd64        Signed kernel image generic
rc  linux-image-5.4.0-31-generic          5.4.0-31.35                                 amd64        Signed kernel image generic
ii  linux-image-5.4.0-33-generic          5.4.0-33.37                                 amd64        Signed kernel image generic
ii  linux-image-5.4.0-37-generic          5.4.0-37.41                                 amd64        Signed kernel image generic
ii  linux-image-extra-4.10.0-42-generic   4.10.0-42.46~16.04.1                        amd64        Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-generic                   5.4.0.37.40                                 amd64        Generic Linux kernel image
ii  linux-image-virtual                   5.4.0.37.40                                 amd64        Virtual Linux kernel image

Zaznaczone paczki należy zablokować przed usunięciem i robimy to z poziomu roota:

echo linux-image-4.10.0-42-generic hold | dpkg --set-selections;
echo linux-image-generic hold | dpkg --set-selections;
echo linux-image-extra-4.10.0-42-generic hold | dpkg --set-selections;

I to tyle. Teraz apt ich nie usunie przy aktualizacji.

Wyświetlanie listy przydziałów z DHCP w FortiGate (CLI)

anzena-forti # anzena-forti # execute dhcp lease-list internal7
internal7
  IP            MAC-Address             Hostname            VCI                 SSID                AP                  Expiry
  192.168.30.102        00:0c:29:2e:9a:42       endpoint-3          MSFT 5.0                                                    Wed Jun 17 13:07:42 2020
  192.168.30.103        00:0c:29:23:aa:4a       xubuntu                                                                         Wed Jun 17 22:03:58 2020
  192.168.30.100        00:0c:29:c9:58:c6       ENDPOINT-1          MSFT 5.0                                                    Fri Jun 19 10:30:52 2020
  192.168.30.104        00:0c:29:7c:6a:73       gns3vm                                                                          Fri Jun 19 11:38:13 2020
  192.168.30.101        00:0c:29:27:fc:19       endpoint-4          MSFT 5.0                                                    Tue Jun 23 08:04:09 2020

Wyłączanie Hyper-V bez jego usunięcia

Hyper-V ma upierdliwą cechę – blokuje działanie innych hypervisorów, przez co jeśli Hyper-V działa, nie mogę pracować na wirtualkach np. na VMware Workstation czy Oracle VM VirtualBoxie. Rozwiązanie jest proste:

bcdedit /set hypervisorlaunchtype off

Po restarcie Hyper-V będzie wyłączone i nie trzeba go usuwać z systemu. Jeśli chcemy je włączyć z powrotem, wystarczy wykonać:

bcdedit /set hypervisorlaunchtype on

i wykonać ponowny restart.

Szybkie tworzenie klucza, CSRek oraz konwersja certyfikatów w OpenSSL

Tworzenie klucza RSA 2048-bitowego:

openssl genrsa –out klucz.key 2048 //nie działa w powershell, tam trzeba podać pełną ścieżkę pliku

Następnie, aby stworzyć CSRkę (certificate signing request) warto mieć do tego przygotowany config. Przykładowy wygląda tak:

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
utf = yes

[ dn ]
C=PL
ST=SL
L=Tychy
O=it.supra.tf
OU=IT
[email protected]
CN = it.supra.tf

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = it.supra.tf

Takie coś zapisujemy do jakiegoś pliku, np. config.cnf.
Następnie tworzymy CSR:

openssl req -new -key klucz.key -out it.supra.tf.csr -config config.cnf

Potem taki CSR musimy wykorzystać do podpisania certyfikatu w naszym CA. Jeśli pobierzemy plik w formacie DER zamiast Base-64, można go skonwertować w ten sposób:

openssl x509 -inform pem -in it.supra.tf.cer -out it.supra.tf.pem

Przy okazji te polecenie się przydaje do sprawdzenia zawartości CSRki:

openssl req -in shadowcontrol.anzenalab.local.csr -text -noout

Certyfikat składa się z certyfikatu serwera oraz łańcucha (serwerów, które potwierdzają ważność certyfikatu (może być ich wiele jeśli mamy wielostopniowe PKI, gdzie jest główny urząd certyfikacji i pośredni). Przykład docelowego certyfikatu:

-----BEGIN CERTIFICATE-----
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
certyfikat serwera
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
certyfikat urzędu certyfikacji, który podpisał certyfikat serwera
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
certyfikat urzędu certyfikacji, który podpisał certyfikat urzędu certyfikacji powyżej
(o ile taki urząd istnieje w PKI)
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD
XDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXDXD=
-----END CERTIFICATE-----

W następujący sposób można sprawdzić, czy certyfikat się zgadza z kluczem:

> openssl x509 -noout -modulus -in phpipam.crt | openssl md5
MD5(stdin)= 1144fb849c1b3abe152a3cbdf9ddce49
> openssl rsa -noout -modulus -in phpipam.key | openssl md5
MD5(stdin)= 1144fb849c1b3abe152a3cbdf9ddce49

Dodatkowo w następujący sposób można skonwertować certyfikat z kluczem do formatu PKCS12:

openssl pkcs12 -export -out it.supra.tf.pfx -inkey it.supra.tf.key -in it.supra.tf.crt

Aktywacja klucza produktu dla Windowsa Server z poziomu CLI

Znalazłem to tutaj.

Dla Windowsa Server Standard:

Dism /online /Set-Edition:ServerStandard /AcceptEula /ProductKey:12345-67890-12345-67890-12345

Dla Windowsa Server Datacenter:

Dism /online /Set-Edition:ServerDatacenter /AcceptEula /ProductKey:12345-67890-12345-67890-12345

Ewentualnym rozwiązaniem może być:

slmgr /ipk 12345-67890-12345-67890-12345

Oczywiście musimy mieć połączenie z Internetem, by wszystko zadziałało.