Is Firewall Logging Enough for Law No. 5651?
On its own, firewall logging is not sufficient for Law No. 5651 in most scenarios. A firewall produces NAT and traffic records; these are an important link in the chain, but they do not bind the record to a person. Law No. 5651 expects you to be able to follow a connection all the way through the chain “public IP:port → internal IP → device → person.” This requires, alongside the firewall log, user authentication (captive portal), DHCP records, and that all of these be timestamped/e-signed and retained for the legal period with integrity intact. Moreover, most firewalls’ local logs are short-lived (they rotate), are unsigned, and — when not collected in one place — are not searchable during an audit.
This page is for information only; consult the current legislation and a legal advisor for definitive obligations.
What does a firewall log provide, and what does it not?
- Provides: NAT mapping (internal IP → public IP:port), traffic time, some session information.
- Does not provide: user identity (who?), often DHCP mapping, integrity proof via signature/timestamp, a long-term searchable archive.
How are the gaps filled?
The firewall record must be combined with a captive portal authentication that binds the user (SMS/form/Turkish ID/sponsor) and with DHCP records. All of these must be collected on a central log server, synchronized to the same NTP clock, and timestamped. We detail which records are needed in the what logs to keep for guest Wi-Fi guide.
The “the firewall already logs” misconception
A firewall producing logs does not mean that record carries evidential value in the sense of Law No. 5651. An unsigned, short-lived record that does not match an identity is open, during an audit, to the objection “it may have been produced later” or “it is unclear who this is.”
How does SignLogger close this gap?
SignLogger collects syslog from FortiGate, Cisco, MikroTik, Sophos, SonicWall, Palo Alto and all other brand firewalls, matches them to captive-portal authentication and DHCP/NAT records, signs them every day with the TÜBİTAK Kamu SM timestamp and e-signature, and provides audit-ready search/export. For the general framework see Law No. 5651 log obligation. Explore the features or request a free demo.
Frequently Asked Questions
FortiGate/SonicWall keep their own logs — why is an extra solution needed?
These devices’ local logs are short-lived and unsigned; they don’t match user identity. Central, signed and searchable retention requires separate log management.
I added a captive portal to my firewall — is that enough?
Authentication is an important step, but records must also be signed, stored centrally and matched to NAT/DHCP.
Is redirecting syslog to a file enough?
No; a file is unsigned and usually not searchable. Integrity (timestamp) and audit reporting are required.
Does the NAT log show the person?
Not on its own; it binds the internal IP to the public IP:port. To reach the person, DHCP and captive-portal identity are needed.
Can it be done without a timestamp?
A timestamp is practically essential for the record’s evidential value; SignLogger performs signing every day with the authorized certification authority (TÜBİTAK Kamu SM) timestamp and e-signature.
Can I collect all brands in one system?
Yes; SignLogger collects syslog brand-independently and unifies it in a single panel.