The 5651 logging guide: obligations, retention and integrity proof

What is Law No. 5651

Law No. 5651, "the Law on Regulating Publications on the Internet and Combating Crimes Committed Through Such Publications," took effect in 2007. It places an obligation on organizations that provide internet access or offer shared internet use to retain certain records about the service they provide and, when required, to produce them to the competent authorities. The goal is to make it possible to later determine who made which connection and when, in support of combating crimes that can be committed over the internet.

Who is obligated

The party most often discussed under the law and its related regulations is the "public internet use provider": a business that offers internet access to its own customers, visitors or students. The most common examples in practice:

• Hotels, guesthouses and other accommodation facilities
• Cafés, restaurants and shopping malls
• Hospitals and healthcare facilities
• Schools, universities and other educational institutions
• Factories, office towers and other workplaces

Article 7/2 of Law No. 5651 places the obligation to block illegal content and keep access records on "all public internet use providers, regardless of whether they operate for commercial purposes" — meaning a hotel, café or office that offers free Wi-Fi to its customers, guests or staff is also within the scope of this obligation. Additional obligations such as an operating permit, a fixed IP, and administrative fines apply only to "commercial public internet use providers" — places like internet cafés that sell internet access for a fee. For the exact wording of the articles and the scope distinction, see the Legislation page and the Law No. 5651 guide.

What the related regulation requires

The Regulation on Internet Public Use Providers asks all public use providers to use a content-filtering system and to keep access records (internal IP, start/end time, MAC, destination IP, NAT IP/port) electronically (Art. 4). For those operating commercially, it additionally asks that a value confirming the accuracy, integrity and confidentiality of the recorded information be logged daily (Art. 5/1-e). In other words, "keeping logs" alone isn't enough — it must also be possible to show that those logs haven't been altered afterward. See the Regulation on Internet Public Use Providers page for the full text of the articles.

Retention period

The regulation sets the retention period for access records explicitly at two years (Art. 4/1-b; and Art. 5/1-d for commercial providers). Phrasing like "at least 1, at most 2 years" or "1 year" isn't based on this article. See the 5651 log retention period guide for details. On the izgate side, retention is a setting you choose from the panel; two years is the suggested/default value, and you're free to change it to whatever period you need.

Why integrity proof matters

The legal value of a log record largely depends on whether it can be shown that it hasn't been altered. A plain-text log file can easily be corrupted by anyone with access to the disk, by adding, deleting or changing lines — and proving afterward that such a change was made is nearly impossible. For this reason, a mature logging system brings together three elements:

• Integrity (hash chain)The digest of each record chunk also carries the digest of the one before it; delete or change a single line and the chain breaks, which is detected instantly.
• Authentication (digital signature)The archive is signed with a secret key unique to your installation; a forged file produced without the signature, or signed with a different key, can't pass verification.
• Proof of time (timestamp)An independent timestamping service confirms, independently of your organization, the moment the record existed — showing the signature wasn't applied after the fact.

How izgate delivers this

izgate writes every log line coming from your firewall to a secure on-disk queue first; a line isn't removed from the queue until it reaches both the search database and the signed archive. This means a power outage or a restart doesn't result in log loss.

On the archive side, the flow looks like this:

• Segmentation: Logs are accumulated per tenant/device/type/day and written to the archive as compressed segment files.
• SHA-256 chain: Each segment's digest is computed and chained with the previous segment's digest; this means not even a single past segment can be silently changed.
• Ed25519 signature: The segment and chain information are signed with an Ed25519 key unique to your installation.
• Daily qualified timestamp: Signed segments for the day that haven't yet been timestamped are combined into a Merkle root, and once a day this root is sealed with a qualified timestamp obtained from Kamu SM via İzHost's central service.
• Live and archive on separate disks: The live database used for fast search and the signed archive are kept on separate physical disks; one filling up or failing doesn't affect the other.

Zero log loss: why it matters

The evidentiary value of a record kept under 5651 is measured not only by its integrity but also by its completeness. A system that drops lines during heavy traffic, or when the server briefly restarts, can later run into an "there's no record for that hour" situation. izgate reduces this risk with a secure on-disk queue placed in front of the syslog receiver: every incoming line is written to the queue first, and it isn't removed from the queue until it's confirmed to have reached both the fast search database and the signed archive. If there's a power outage or the service restarts, lines still waiting in the queue continue to be processed from where they left off.

The same principle applies on the device side: izgate identifies every device by its serial number, not its IP address. Even if a firewall's IP address changes (a DHCP renewal, a network reconfiguration), logs keep going to the right device as long as the serial number stays the same — otherwise two different devices sharing an address could have their records mixed up or merged by mistake.

User matching

A raw traffic record only shows an IP address and a time; it doesn't answer "who was on this IP at that time?" izgate automatically merges identity information from the guest portal and RADIUS sessions with firewall logs; the search screen can filter by user, MAC address, or alias code. For guest records, the real identity (phone/Turkish ID number) is never written to the firewall or the logs; every guest is assigned a fixed alias code (mg-xxxxxx), and the firewall/RADIUS username and the log's user= field carry this code; the alias-to-identity mapping is kept encrypted only inside izgate and is resolved only on the authorized search screen.

Archive verification and export

When a request comes in from law enforcement or judicial authorities, you can export the records for the relevant period as a single package. The exported package contains the following components:

• README: A short text explaining how to verify the package.
• Catalog: The list of segments, chain order and digest information.
• Segment files: The compressed raw log data.
• Manifest: The segment's digest, the previous segment's digest, and the digital signature.
• TSA token: The independent proof of time obtained from the timestamp server.

The integrity of any segment, or the entire chain, can be verified with one click from the panel: the hash chain, signature and timestamp are checked together, and the result is reported as either "chain intact" or exactly where the error is.

Log transport: UDP, TCP and TLS

Firewalls typically send logs using the syslog protocol; but the transport method directly affects reliability. izgate supports all three methods together:

• UDP: The most common and easiest method to set up, but it produces no warning on either the sender or receiver side when packets are lost; it's exposed to silent data loss on busy networks.
• TCP: Because it's connection-based, the chance of packet loss drops significantly; data is resent after a brief interruption.
• TLS: In addition to TCP's reliability, it encrypts log content in transit over the network; izgate accepts this path too once a certificate is configured.

Moving to TCP or TLS wherever the device allows strengthens integrity, especially during busy hours and for log shipping from remote locations.

Compliance checklist

• Are the logs from every firewall/access point on your network collected centrally?
• Are logs sent over a reliable transport (TCP/TLS, a loss-proof queue), or over plain UDP, which carries loss risk?
• Are records protected by a hash chain, a digital signature and an independent timestamp?
• Are live and archive records kept on separate disks?
• Is there an automatic match between guest/user identity and traffic records?
• Was your retention period set according to current legislation?
• Can you export the relevant period in a signed, verifiable form when a request comes in?

Common mistakes

• UDP loss: Plain UDP syslog can silently lose lines during network congestion or a brief interruption on the receiving side; the loss can go unnoticed for months.
• Unsigned plain files: Log files that are only written to disk, without a signature or a chain, may technically look "kept," but they provide no integrity proof; whether they were altered can neither be proven nor ruled out.
• No user matching: In systems that only keep IP-based records, on shared networks (guest Wi-Fi, behind NAT) it later becomes impossible to determine which person made which connection.
• A single disk filling up: In setups where live and archive data share the same disk, once it fills up either logging stops or old records are silently deleted; a separate disk and a fill-level alert reduce this risk.

Frequently asked questions

Explore guest Wi-Fi authentication