What to Log for Reliable IP Address Investigations
Logs are records of what a system did or observed. Useful logs let you answer what happened, when it happened, and which connection or account was involved. Keeping those details together helps you investigate suspicious activity, report abuse, and diagnose problems.
1. Which fields should I capture?
Keep the connection details, the action, its outcome, and identifiers that link related records together in one event. A source IP is the sender's address; a destination IP is the recipient's. A port is a number that distinguishes an application or exchange of data at an address. A protocol, such as TCP or UDP, defines how traffic is exchanged. The observation point is the system that recorded the connection. A later lookup cannot recover details that were never logged.
Practical checklist
When did it happen? timestamp
Which system recorded it?
What event occurred?
Who or what account was involved?
Which source connected? source_ip, source_port
Which destination received it? destination_ip, destination_port
Which network protocol was used? protocol
Where was the connection observed?
Which service or application handled it?
Was the action allowed or denied?
What was the result?
What non-secret request, session-correlation, or trace ID links related events?
For account-related investigations, also include account ID, a non-secret session correlation ID, authentication method, device or client information, user agent, risk or fraud signals, action taken, and result. Never use an active session token as the correlation value.
Use structured logs
Structured logs are easier to search, validate, and correlate than free-form messages. Prefer JSON or another structured event format with clear field meanings and consistent types.
Better:
{
"event_type": "authentication.login_failed",
"timestamp": "2026-06-18T14:32:45.183Z",
"account_id": "acct_12345",
"source_ip": "203.0.113.24",
"source_port": 51842,
"destination_ip": "198.51.100.10",
"destination_port": 443,
"protocol": "TCP",
"observation_point": "internet-edge",
"user_agent": "Mozilla/5.0 ...",
"request_id": "req_9f27c1",
"result": "failed",
"failure_reason": "invalid_password"
}Risky:
User acct_12345 failed login from 203.0.113.24Free-form text can supplement a structured event, but it should not be the only record. Treat user-controlled values as data. Escape carriage returns, line feeds, delimiters, and other control characters so input cannot create fake entries, break JSON, or hide fields.
Use consistent field names
source_ip
source_port
peer_ip
peer_port
destination_ip
destination_port
protocol
observation_point
event_type
timestamp
account_id
request_id
session_correlation_id
result
Normalize different producer schemas during ingestion while preserving the original event where appropriate. Document whether source_ip and source_port were observed at the public edge or derived later. Use separate peer fields for a proxy's connection to the backend.
Keep safe request and correlation IDs
A unique request or correlation ID connects an action across load balancers, proxies, application services, queues, databases, background workers, and audit logs.
Generate it at a trusted edge, or validate and replace a value supplied by the client. Bound its length and allowed characters before logging it. A client-controlled identifier must not forge log structure or attach an event to another user's trace.
2. How do I keep timestamps and client addresses accurate?
Record when and where a connection was observed. Shared addresses and proxy chains make an IP address alone too ambiguous for reliable attribution.
Use precise UTC timestamps
Record seconds or better in a consistent format with timezone information:
2026-06-18T14:32:45.183ZAvoid ambiguous timestamps:
06/18/26 14:32The second value changes meaning by locale and omits seconds and timezone. Synchronize systems with reliable time sources such as Network Time Protocol (NTP). Keep original event time separate from ingestion time.
A timestamp supplied by a remote client or system reflects a clock you may not control. Preserve that reported time, record the collector's receipt or ingestion time, and keep clock-sync status or estimated uncertainty when available. Do not claim event ordering or precision finer than the known clock uncertainty.
Why source IP is not enough
Network Address Translation (NAT), Carrier-Grade NAT (CGNAT), VPN gateways, mobile networks, and other shared systems let many users appear under one public address. For CGNAT correlation, the company providing Internet access (the Internet Service Provider, or ISP) generally needs the exact UTC time, public source IP and source port, and transport protocol. Keep the destination IP and port too.
Better:
{
"timestamp": "2026-06-18T14:32:45.183Z",
"source_ip": "203.0.113.24",
"source_port": 51842,
"destination_ip": "198.51.100.10",
"destination_port": 443,
"protocol": "TCP",
"observation_point": "internet-edge",
"service": "api-gateway",
"account_id": "acct_12345",
"request_id": "req_9f27c1",
"action": "login_attempt",
"result": "failed"
}Risky:
Login failed from 203.0.113.24 on 2026-06-18 14:32:45The weak record lacks timezone, source port, protocol, destination details, observation point, and account context. The better example assumes the source and destination addresses, their ports, and the protocol were all recorded on the same Internet-facing connection. Together these fields are called a connection tuple.
Record the client and immediate peer separately
A content delivery network (CDN) serves content through distributed servers. A load balancer spreads requests among servers, and a reverse proxy receives requests on a website's behalf. Behind any of these services, your application's direct connection comes from that intermediary, called its immediate peer. Derive the client IP only through a forwarding path you trust, and log both the derived client address and the immediate peer address.
Keep their ports separate too. The backend source port belongs to the immediate peer. Do not pair that proxy port with a forwarded client IP and call it the client's connection. Capture the visitor's public source port at the Internet-facing edge or retrieve it from a documented, authenticated provider field or edge log. Ordinary X-Forwarded-For data does not reliably carry that port.
See How to Find the Real Client IP Behind a Proxy and X-Forwarded-For Header: Format, Examples and Security.
Preserve historical context
Registration, routing, reverse DNS, reputation, and location data change. If you enrich an event, keep the lookup time and the source name and version for each result. This prevents a later lookup from being mistaken for the context that was available during the investigation.
{
"timestamp": "2026-06-18T14:32:45.183Z",
"source_ip": "203.0.113.24",
"source_port": 51842,
"observation_point": "internet-edge",
"routing": {
"asn": 64500,
"source": "routing-snapshot",
"source_version": "2026-06-18T14:00:00Z",
"lookup_time": "2026-06-18T14:32:46.001Z"
},
"registration": {
"holder": "Example Network Ltd",
"source": "registration-snapshot",
"source_version": "2026-06-18",
"lookup_time": "2026-06-18T14:32:46.100Z"
},
"location": {
"country": "PL",
"source": "location-dataset",
"source_version": "2026-06-17",
"lookup_time": "2026-06-18T14:32:46.120Z"
}
}3. How should I protect and retain IP logs?
Logs often contain personal and security-sensitive data. Collect what the investigation needs, restrict access, protect integrity, and delete data according to a deliberate policy.
Do not log secrets
Avoid passwords, session tokens, API keys, private keys, authorization headers, raw Cookie or Set-Cookie headers, password-reset tokens, multi-factor authentication (MFA) recovery codes, full payment-card numbers, and unnecessary personal data.
Do not record raw URLs, query strings, request or response bodies, or arbitrary headers by default. They often contain credentials, tokens, search terms, or personal data. Allowlist the fields needed for a defined purpose and redact sensitive values before logs leave the producer.
Prefer opaque random identifiers created for logging, partial or redacted values, or a separate protected audit store. When an enumerable identifier must remain consistently linkable, use a keyed hash-based message authentication code (HMAC) and store the key separately from the logs. A conventional hash, even with a salt, does not safely pseudonymize a small or predictable identifier space against enumeration.
Better:
{
"api_key_id": "key_abc123",
"result": "denied"
}Risky:
{
"api_key": "sk_live_full_secret_value_here",
"result": "denied"
}Protect log storage and integrity
Send important logs to a centralized location where an attacker who compromises one host cannot easily change or delete them.
Centralized collection
Restricted write access
Separate administrative access
Append-only storage where appropriate
Integrity checks
Backup or archival storage
Encryption in transit and at rest
Alerting on logging failures
Auditing of reads and searches
Auditing of exports and admin actions
High-value audit logs may need immutable storage, cryptographic signing, or write-once retention controls. Record and monitor reads, searches, exports, and administrative access to sensitive logs, and keep that access trail outside the control of ordinary log readers.
Set retention by risk and log type
Authentication, administrative, payment-related, and security logs may need longer retention than routine debug output. Base the period on investigation needs, legal and privacy obligations, data sensitivity, incident timelines, support needs, and storage cost. Deleting too early can prevent an investigation; keeping sensitive logs forever creates unnecessary risk.
Keep audit and debug logs separate. Audit schemas should be stable, structured, protected, and carefully retained. Debug logs change more often, can contain implementation details, and may be sampled or kept for less time.
Login and failed login
MFA challenge
Password or email change
API key creation
Permission or admin action
Data export
Billing change
Account deletion
4. How should I validate and interpret IP logs?
Test that the records are complete and usable before an incident. Then describe what the system observed without turning an IP address or lookup result into a claim about a person.
Validate that logging works
Teams often discover too late that a field was missing, clocks disagreed, edge ports were not captured, logs were dropped under load, or retention was shorter than expected.
Test incident investigations
Log completeness checks
Schema validation
Alerting on missing fields
Alerting on ingestion delays
Sample investigation queries
Periodic access reviews
Retention verification
A log that cannot be found, trusted, parsed, or correlated during an incident is not useful evidence.
Do not rely on IP data alone
An IP address is a network signal, not a stable identity. A dynamic IP address may be reassigned. A shared address can represent many users. A location estimate may be wrong, and a reverse DNS name may be stale, generic, or deceptive.
Account and login history
Authentication and MFA events
Device or browser security signals
Session behavior
Fraud indicators
Payment or support context
Registry and routing data
DNS and provider records
The stronger the consequence, the stronger and more independent the supporting evidence should be.
Phrase findings as observations
| Better | Risky | Why |
|---|---|---|
| The edge logs recorded a failed login from this source IP and source port at this UTC time. | This person attempted the login. | The record proves what the system observed; identity needs supporting evidence. |
| The named IP geolocation sources agree at country level. | The person was in this city. | Location is supporting context, not proof of a person's precise location. |
What good logs achieve
Good logs capture the connection details an investigation needs, preserve the context that existed at the time, protect sensitive data, and support conclusions that are accurate, defensible, and fair.