A common source of confusion for businesses: "Which logs do I actually need to keep?" In this article we walk through each of the log types that carry a legal obligation, one by one.
Mandatory Log Types
1. Session (Connection) Logs
The core records that must be kept for every internet session:
- The user's source IP address (static or dynamic)
- The user's source port
- Destination IP address
- Destination port
- Protocol used (TCP, UDP, ICMP, etc.)
- Session start time
- Session end time
- Amount of data transferred (bytes)
2. NAT Logs
The record of which external IP an internal IP was translated to on the outside network. This is mandatory whenever an access provider or corporate NAT is in use.
- Internal IP / internal port
- External IP / external port (after NAT)
- Translation start and end time
3. Hotspot User Records
Mandatory for mass-use providers:
- The user's mobile phone number (SMS verification)
- Turkish national ID number (where required)
- Full name
- MAC address of the connecting device
- Assigned IP address
- Session start and end time
4. DHCP Logs
Records showing which IP was assigned to which MAC address:
- MAC address
- Assigned IP address
- Lease duration
- Lease start and end time
5. DNS Query Logs (Recommended)
Not mandatory, but valuable in a forensic investigation:
- IP that made the query
- Domain name queried
- Query time
6. Authentication / RADIUS Logs
Authentication records (especially where 802.1X is in use):
- Username
- Authentication method
- Authentication result (success/failure)
- Client device information
Devices That Should Generate Logs
- Firewall: FortiGate, Palo Alto, Cisco ASA, SonicWall, Check Point, Sophos, WatchGuard
- Router/Switch: MikroTik, Cisco, Juniper, HP/Aruba, H3C
- Wireless Controller: Aruba, Ruijie, Ubiquiti, Cisco WLC, Meraki
- Server: Active Directory (logon/logoff), Linux (auth.log)
- Hotspot/NAC: SignLogger Hotspot, Cisco ISE
Log Integrity and Time Synchronization
Every log you keep must:
- carry a timestamp synchronized via NTP;
- have its integrity provable through an electronic signature or hash chain;
- be sealed with a timestamp issued by an authorized body such as TÜBİTAK Kamu SM;
- be stored in an encrypted environment protected against unauthorized access.
Every Log Type with SignLogger
SignLogger gathers all of the log types above on a single central platform, normalizes them, seals them with an electronic signature, and makes them ready to search. In SignLogger, signing approved by an authorized certificate authority is performed through the integration with TÜBİTAK Public Certification Authority (Kamu SM): during the integration step, each customer defines their own Kamu SM username and password in SignLogger and buys the timestamp credit from Kamu SM in their own name. When no timestamp credit is available, daily logs are still signed using the server's own certificate and timestamp. For details, see our documentation.
Log Sources by Device Type
| Source | Logs produced | Collection method |
|---|---|---|
| Firewall / UTM | Session (connection), NAT, web filtering | Syslog (UDP/TCP 514), CEF |
| DHCP server | IP–MAC mapping records | Syslog or agent (SignAgent for Windows DHCP) |
| Wireless controller / AP | Client association, roaming | Syslog |
| Hotspot / captive portal | User authentication and session records | RADIUS accounting, portal database |
| Proxy / DNS server | Domain name and URL access | Syslog |
| Windows servers | Logon events, event logs | Agent-based collection with SignAgent |
The Prerequisite for Correct Logging: Time Synchronization
In a forensic request, the NAT log, DHCP record and hotspot session have to be correlated to the second. That is exactly why every device must be synchronized to the same NTP source; even a 30-second drift can point to the wrong user. In SignLogger deployments, NTP configuration is the very first item on the checklist.
Format and Transport: Syslog or CEF?
Most devices send standard syslog (RFC 5424); enterprise firewalls also support CEF (Common Event Format), which makes field-level parsing easier. SignLogger accepts both. A sample CEF configuration for Palo Alto is covered in this guide. UDP is the common transport; in high-volume environments where lossless delivery is required, TCP may be preferred.
Case Study: How Is a Forensic Request Correlated?
Let's see why the process needs so many log types by walking through a scenario. Suppose law enforcement submits the following request: "The identity of the user who, at 21:47 on 12 March 2026, accessed the following address from IP X.X.X.X on port 44321."
- NAT log: The internal source of the connection using external IP X.X.X.X:44321 at 21:47 is located →
10.5.50.23:51544. - DHCP log: The MAC address that IP 10.5.50.23 was assigned to at that moment is identified →
AA:BB:CC:DD:EE:FF. - Hotspot session record: The authenticated user whose open session used that MAC is found → an SMS-verified +90 5xx ... number.
- Timestamp: All three records come from the signed archive, proving that none of them were altered afterward.
If a single link in the chain is missing (for example, if the DHCP log was never kept), the correlation cannot be traced all the way down to the individual, and the obligation may be deemed unmet. For how to collect all four of these sources on a single platform, see the Law No. 5651 Logging Obligation guide.
Frequently Asked Questions
Do we need to record content (packet payload)?
No — Law No. 5651 requires traffic metadata (who, when, where); recording packet payload is not required and, from a KVKK standpoint, is not recommended either.
In what order are logs processed?
Collection → normalization → writing to daily files → timestamp + electronic signature → compressed archive. For the details of the signing step, see the article Signed Logs and Timestamping.
Can I collect everything on a single platform?
Yes — SignLogger collects firewall, DHCP, AP, hotspot and Windows sources on a single server; for an overview, see the Law No. 5651 Logging Obligation guide and the features page.