Informacje Lokalne

ZdrowiePOLSKALOKALNESWIATHYDEPARK

Audyt techniczny. Węgry

Opublikowano: 11.02.2026 | Autor: Grzegorz GPS Świderski | Ostatnia aktualizacja: 11.02.2026 18:25

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.
  2. 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).
  3. 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

Dodaj komentarz: