Can I mask IP addresses in the logs for KVKK / GDPR?

Q: Can I mask IP addresses in the logs for KVKK / GDPR?

Yes. In an HTTP vService, the Ip Log Masking action reduces the client IP address to the selected mask (Masking(subnet) default 24); for example, 203.0.113.45 is written to the records as 203.0.113.0. The action takes no conditions and runs in the request stage, at its position in the action list of the vService. Since the source address of the request is masked from this point on, the lines that go to the log server, HTTP Logs and Debug Mode Logs in Logs & Tracking, vService Report records and the X-Forwarded-For header that goes to the Backend Service carry the masked address. WAF event logs, IPFIX records, live statistics tables and quarantine counters continue to keep the real address; conditions such as Source IP are also evaluated with the real address. The mask is applied only to IPv4 addresses and must be used in the 0–32 range.

Short answer

Yes. In an HTTP vService, the Ip Log Masking action reduces the client IP address to the selected mask (Masking(subnet) default 24); for example, 203.0.113.45 is written to the records as 203.0.113.0. The action takes no conditions and runs in the request stage, at its position in the action list of the vService. Since the source address of the request is masked from this point on, the lines that go to the log server, HTTP logs and Debug Mode Logs in Logs & Tracking, vService Report records and the X-Forwarded-For header that goes to the Backend Service carry the masked address. WAF event logs, IPFIX records, live statistics tables and quarantine counters continue to keep the real address; conditions such as Source IP are also evaluated with the real address (masked and unmasked records). The mask is applied only to IPv4 addresses and must be used in the 0–32 range.

Problem: The IP Address Is Kept in the Logs as Personal Data

Under KVKK and GDPR, the IP address can be considered personal data; writing the full address to the log server and to the records on the device increases the retention and access obligations. The addresses are required to be written to the records in anonymized form.

Solution

Masking is done with a single action added to the HTTP vService. Since the action changes the source address of the request, it affects not only the log line but everything that comes after it in the order; the order is therefore important.

Ip Log Masking

How it works The source address of the client is replaced with the masked value at the position of the action in the vService action list. From this point on, the records and actions that read the address see the masked address; conditions, WAF, Bot/DDoS and quarantine continue to use the real address.
Where it is openedLoad Balancer → Actions → Action Type = Ip Log Masking
Requirement HTTP vService
vService type HTTP
Backend Service side If X-Forwarded-For is on in the vService, the Backend Service also receives the masked address. If the application needs the real address, the address is passed in a separate header with an Add HTTP Header action ordered before the masking.

Step-by-Step Configuration

Adım 1 Open the action form

On the Load Balancer → Actions screen, the Add button is clicked.

Adım 2 Define the mask

Action Name is entered, Action Type = Ip Log Masking is selected and Masking(subnet) is entered: the default 24 zeroes the last octet, and 16 zeroes the last two octets. The form accepts values up to 128; a value greater than 32 does not produce a valid configuration. There is no condition field in the action.

Adım 3 Save the action

The Add button is clicked.

Adım 4 Open the vService edit form

On the Load Balancer → Load Balancer vService List screen, the HTTP vService is right-clicked and Edit is selected.

Adım 5 Add and order the action

The action is selected in the Actions field in the Details panel. The actions ordered before the masking in the list see the real address (the scope of the masking). Actions that use the Blacklist IP Category condition are ordered before the masking; if they are ordered after it, the lookup is done with the masked address and there is no match.

Adım 6 Save

The Save button is clicked. The progress of applying the change is followed from the sync indicator at the bottom right of the screen. In a cluster setup, with the default auto-sync, the change is also sent to the peer device; if Manual Sync Mode is on, it is sent manually with Synchronize.

Verification

1Device logsTR7 side

In the Logs & Tracking tab of the vService screen, the HTTP logs source is selected and the client address of new requests is checked.

Expected203.0.113.0

2Log server and Backend ServiceExternal systems

The client address is checked in the line arriving at the log server and in the X-Forwarded-For value in the access log of the Backend Service.

ExpectedMasked address

Common Mistakes

Assuming that masking is applied to all records. WAF event logs, IPFIX records, live statistics tables and quarantine counters keep the real address; the KVKK assessment must cover these as well.
Assuming that IPv6 clients will also be masked. The mask is applied only to IPv4 addresses; IPv6 addresses are written to the records as they are.
Expecting the application to receive the real address in X-Forwarded-For. The Backend Service also receives the masked address; if the real address is needed, it is passed with a separate header ordered before the masking.
Forgetting the requests that terminate before the masking. Requests terminated by Bot/DDoS protection or by Block, Show content or Redirect actions ordered before the masking in the list are recorded with the real address.
Looking for the action in an L7 TCP vService. Ip Log Masking exists only in an HTTP vService; TCP logs are not masked.

How it is done in the documentation

Can I mask IP addresses in the logs for KVKK / GDPR? ​

Problem: The IP Address Is Kept in the Logs as Personal Data ​

Solution ​

Ip Log Masking ​

Step-by-Step Configuration ​

Verification ​

Common Mistakes ​