FORUM
ID
ID TABLICA Niezalogowany
GPS
Autor: GPS
Opublikowano: 11.02.2026 | Ostatnia aktualizacja: 17.05.2026 18:59 | 👁 18

Audyt techniczny. Węgry

Węgry — NAV Online Számla (endpoint: api.onlineszamla.nav.gov.hu)

1. Cel badania

Celem audytu jest ustalenie, czy węgierski system clearance działa za zewnętrzną usługą WAF/CDN, czy też posiada krajową, państwową warstwę brzegową, a jeśli tak — jakiego typu to warstwa (chmura vs urządzenie brzegowe).

2. Krok 1 — DNS

Komenda

Resolve-DnsName api.onlineszamla.nav.gov.hu -Type A
Resolve-DnsName api.onlineszamla.nav.gov.hu -Type CNAME
Resolve-DnsName nav.gov.hu -Type NS
Resolve-DnsName nav.gov.hu -Type SOA

Wynik

    • api.onlineszamla.nav.gov.hu → A = 84.206.52.73, TTL 60
    • brak CNAME
    • NS dla nav.gov.hu: adns0.gov.hu, adns1.gov.hu, adns2.gov.hu, ns.nav.gov.hu

Interpretacja

Brak CNAME oznacza brak widocznej integracji z globalnym CDN/WAF-as-a-Service (Imperva, Cloudflare, Akamai itd.) na poziomie DNS. Serwery nazw w domenie gov.hu sugerują państwową kontrolę strefy DNS.

3. Krok 2 — HTTP/HTTPS (nagłówki i odcisk palca brzegu)

Komenda

curl.exe -vkI https://api.onlineszamla.nav.gov.hu/

Wynik (kluczowe fragmenty)

    • HTTP/1.1 200 OK
    • brak Server
    • brak Via
    • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
    • Set-Cookie: NAVHVR=!<opaque_blob>; path=/; HttpOnly; Secure

Interpretacja

Cookie NAVHVR=!… ma format typowy dla warstwy brzegowej realizującej „persistence” (sticky session) lub token routingu. To jest silny sygnał obecności reverse proxy / ADC / LB / WAF na brzegu — niezależnie od tego, czy infrastruktura jest państwowa, czy zewnętrzna. Brak charakterystycznych ciastek Imperva/Cloudflare/Akamai wzmacnia wniosek, że to nie jest popularny WAF-as-a-Service.

4. Krok 3 — polityka TLS (wersje protokołu)

Komendy

curl.exe -vkI --tlsv1.2 https://api.onlineszamla.nav.gov.hu/
curl.exe -vkI --tlsv1.3 https://api.onlineszamla.nav.gov.hu/

Wynik

    • TLS 1.2 → działa (200 OK)
    • TLS 1.3 → odrzucony (SEC_E_ILLEGAL_MESSAGE)

Interpretacja

Odrzucanie TLS 1.3 przy jednoczesnym dopuszczeniu TLS 1.2 jest profilem konserwatywnym. Taki profil częściej spotyka się w:
    • infrastrukturze państwowej,
    • urządzeniach brzegowych (ADC/WAF),
    • środowiskach o twardo ustawionych politykach kompatybilności,
niż w nowoczesnych usługach chmurowych, które zwykle promują TLS 1.3.

5. Krok 4 — zachowanie na błędnych ścieżkach i metodach

Komendy

curl.exe -vkI https://api.onlineszamla.nav.gov.hu/nonexistent
curl.exe -vk -X OPTIONS https://api.onlineszamla.nav.gov.hu/ -o NUL

Wyniki

/nonexistent

    • HTTP/1.1 404 Not Found
    • transfer-encoding: chunked
    • brak content-type
    • cookie NAVHVR=!…

OPTIONS /

    • HTTP/1.1 500 Internal Server Error
    • content-type: application/octet-stream
    • content-length: 409
    • cookie NAVHVR=!…

Interpretacja

Odpowiedzi 404 „bez content-type” i 500 na OPTIONS wyglądają jak generowane przez warstwę pośrednią (proxy/ADC/WAF), a nie przez typową aplikację REST. To wzmacnia tezę, że endpoint jest chroniony/obsługiwany przez bramkę brzegową.

6. Krok 5 — OpenSSL: certyfikat i łańcuch CA (dowód kryptograficzny)

Komenda

openssl s_client `
  -connect api.onlineszamla.nav.gov.hu:443 `
  -servername api.onlineszamla.nav.gov.hu `
  -tls1_2 -showcerts

Wynik (kluczowe fragmenty)

Łańcuch certyfikatów

    • Root CA: Microsec e-Szigno Root CA 2009 (Microsec Ltd., Budapest, HU)
    • Intermediate CA: e-Szigno Class3 SSL CA 2017 (Microsec Ltd., organizationIdentifier=VATHU-23584497)
    • Cert serwera (leaf): CN=*.onlineszamla.nav.gov.hu, O=Nemzeti Adó- és Vámhivatal (węgierski urząd skarbowo-celny)

SAN

    • onlineszamla.nav.gov.hu
    • *.onlineszamla.nav.gov.hu

Parametry TLS

    • Protocol: TLSv1.2
    • Cipher: ECDHE-ECDSA-AES128-GCM-SHA256
    • No ALPN negotiated
    • Verify return code: 0 (ok)

Interpretacja

To jest kluczowy dowód:
    1. Certyfikat jest wystawiony bezpośrednio dla organizacji państwowej: Nemzeti Adó- és Vámhivatal.
    1. CA jest węgierska (Microsec/e-Szigno), czyli nie widać tu globalnych komercyjnych CA typowych dla „cloud edge” (choć samo CA nie przesądza o WAF, jest silnym tropem o lokalności ekosystemu).
    1. Brak ALPN (brak negocjacji HTTP/2) jest spójny z obserwacją curl — wskazuje na konserwatywne ustawienia brzegu.

7. Ogólna ocena: kto robi WAF / warstwę brzegową

Fakty, które mamy na twardo

    • DNS bez CNAME → brak globalnego WAF/CDN na poziomie DNS
    • IP wygląda na krajowy/państwowy (a na pewno nie hyperscaler/CDN)
    • cookie NAVHVR=!… → istnieje warstwa pośrednia (LB/ADC/WAF)
    • TLS 1.3 odrzucany, TLS 1.2 dozwolony → profil konserwatywny (często urządzenia brzegowe)
    • certyfikat wystawiony dla NAV, CA lokalna (Microsec/e-Szigno)

Wniosek techniczny

Węgierski system clearance wygląda na utrzymywany w modelu krajowa (państwowa) warstwa brzegowa + urządzenie typu ADC/LB/WAF działające na własnym IP, bez śladów WAF-as-a-Service. Nie da się z tych danych wskazać konkretnego producenta urządzenia (F5/Citrix/Radware/Forti itd.), bo nagłówki są celowo niemówiące, ale zebrane dowody wykluczają typowy zewnętrzny WAF w chmurze” i wskazują na brzeg kontrolowany lokalnie.

8. Puenta porównawcza

Węgry to przypadek jakościowo inny od Polski:
    • Polska: architektura zewnętrznego WAF (Imperva) i terminacja TLS poza infrastrukturą państwową.
    • Węgry: cert dla urzędu, lokalne CA, własny brzeg i urządzenie pośrednie, ale bez chmury WAF-as-a-Service.

Grzegorz GPS Świderski Kanał Blogera GPS GPS i Przyjaciele X.GPS65