This blog post explains one important aspect of cybersecurity investigations — identifying external users or attackers through internet connection records and network-level evidence. In real-world security incidents, investigation approaches may differ depending on the nature of the attack, affected systems, business impact, regulatory requirements, and available technical evidence.
Some incidents may require web application analysis, malware forensics, endpoint investigation, insider activity review, cloud audit analysis, database forensics, email tracing, or legal and compliance procedures in addition to network-level investigation. The purpose of this article is to help organizations understand how proper logging, IP tracking, timestamps, NAT awareness, and ISP-related information can significantly improve investigation readiness when incidents originate through external internet connectivity.
In today’s digital world, cybersecurity incidents are no longer rare events. Network attacks, website hacking, phishing, malware infections, data breaches, online scams, and unauthorized access attempts have become common risks for almost every organization connected to the internet.
Many organizations invest in firewalls, antivirus systems, endpoint protection, access control, secure coding practices, vulnerability scanning, and security awareness training. These preventive actions are essential. However, one important truth must be accepted:
Even with strong security controls, incidents can still happen. A web application may have an unknown vulnerability. A user may fall victim to phishing. A server may be exposed with weak configuration. A third-party plugin may be compromised. A cloud credential may be leaked. An attacker may abuse your public-facing services.
Therefore, cybersecurity planning should not only focus on prevention. It must also focus on investigation readiness.
If your organization, website, or server is attacked today, are you ready to provide the technical evidence required for an investigation?
Why Investigation Readiness Matters
After a security incident, most organizations immediately ask: “Who attacked us?” Unfortunately, this question is not easy to answer unless proper logs were collected before the incident.
Cybersecurity investigation depends heavily on historical technical evidence. If the required logs are missing, incomplete, wrongly timed, or overwritten, it becomes extremely difficult to identify the source of the attack.
In many cases, the organization may need support from Internet Service Providers, cloud service providers, hosting providers, law enforcement authorities, cybercrime investigation teams, internal IT teams, firewall administrators, and system administrators.
However, these parties can only help effectively if you provide accurate technical details.
The Most Important Evidence: The Five-Tuple
For most internet-related security investigations, the most important information is a set of five values commonly called the five-tuple.
| No. | Information | Example | Why It Matters |
|---|---|---|---|
| 1 | Date and Time | 2026-05-10 14:35:22 | Required to search historical logs accurately |
| 2 | Source IP Address | 203.0.113.xxx | Shows where the connection appeared to originate |
| 3 | Source Port | 51432 | Critical when ISP uses NAT or CGNAT |
| 4 | Destination IP Address | 198.51.100.xxx | Identifies your public IP or service that was attacked |
| 5 | Destination Port | 443 | Identifies the service such as HTTPS, SSH, DNS, or SMTP |
Without these five details, investigation becomes incomplete, especially in IPv4 networks where NAT is widely used.
1. Date and Time of the Incident
The first and most important detail is the exact date and time when the suspicious activity occurred.
2026-05-10 14:35:22
This timestamp must be accurate. If your server clock is wrong by even a few minutes, the investigation may fail. Internet Service Providers and cloud providers process millions of sessions. They search historical logs based on exact time windows.
Therefore, all servers, firewalls, routers, proxies, web servers, DNS servers, mail servers, and security systems must be synchronized with a reliable NTP server.
NTP stands for Network Time Protocol. It ensures that devices use accurate and consistent time.
- Correct system time
- Correct timezone configuration
- NTP synchronization enabled
- Logs stored with timestamps
- Preferably UTC or clearly defined local time
- Consistent time format across systems
2. Source IP Address
The source IP address is the IP address from which the suspicious connection appears to originate.
Source IP: 203.0.113.xxx
In simple terms, this is the attacker-facing IP visible to your system.
Private IP Addresses
Private IP addresses are used inside local networks. Examples include:
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
Public IP Addresses
Public IP addresses are globally routable on the internet. These are the IP addresses visible to external websites and service providers.
You can use Duleep.com to quickly view the public IP address currently used by your internet connection.
In most internet-based security incidents, the attack will appear to come from a public IP address. However, source IP alone is no longer enough in many IPv4 environments.
3. Source Port
The source port is one of the most commonly missed but extremely important details.
Source Port: 51432
Many organizations only log source IP addresses. This is not enough because many Internet Service Providers use NAT, especially CGNAT, which stands for Carrier Grade NAT.
CGNAT allows many customers to share the same public IPv4 address. When multiple users share one public IP address, the ISP must use port numbers to identify the actual customer session.
If you only provide the source IP address, the ISP may not be able to identify the exact customer. But if you provide the source IP, source port, and accurate timestamp, the ISP has a much better chance of tracing the connection.
4. Destination IP Address
The destination IP address is the IP address of your server, firewall, website, application, or service that received the connection.
Destination IP: 198.51.100.xxx
If your organization has multiple public IP addresses, you must know which public IP was attacked.
- Web server public IP
- Mail server public IP
- VPN gateway public IP
- DNS server public IP
- Firewall NAT public IP
- Cloud load balancer IP
- CDN-facing IP
5. Destination Port
The destination port shows which service was targeted.
80 - HTTP 443 - HTTPS 25 - SMTP 53 - DNS 22 - SSH 3389 - RDP 1812 - RADIUS
Destination port helps investigators understand what service was involved. If a web server was attacked, the destination port may be 80 or 443. If a mail server was abused, the port may be 25, 465, or 587.
Why IP Address Alone Is Not Enough
Many people believe that capturing an attacker’s IP address is enough. In modern networks, this is usually not true.
Due to IPv4 address shortage, many ISPs use NAT technologies. A single public IP address may represent hundreds or thousands of users at the same time.
Date and time Source public IP Source port Destination IP Destination port
These details are required to identify the correct user behind a public IPv4 address.
The Role of Law Enforcement
In many countries, Internet Service Providers cannot directly disclose customer identity details to private organizations. Even if you provide accurate logs, the ISP may require an official request from a law enforcement authority or cybercrime investigation unit.
Therefore, after a serious incident, your organization may need to preserve internal logs, prepare a formal incident report, file a complaint with the relevant law enforcement authority, provide the five-tuple evidence, and request the authority to obtain subscriber or session details from the ISP.
Logging at the Perimeter Firewall
If your organization uses NAT internally, your internal server logs may not show the same source information seen by the internet. Therefore, important logs must be captured at the perimeter device.
- Internet firewall
- Router
- NAT gateway
- Load balancer
- Reverse proxy
- Web application firewall
- Cloud security gateway
Timestamp Source IP Source port Destination IP Destination port Protocol Action allowed/blocked NAT translated IP/port Firewall rule ID
Apache Web Server Logging
Apache default access logs usually capture client IP address, timestamp, request, status code, and user agent. However, they may not always capture source port and destination port by default.
Example Apache custom log format:
LogFormat "%t src_ip=%a src_port=%{remote}p dst_port=%p method=%m uri=%U query=%q status=%>s bytes=%B referer=\"%{Referer}i\" user_agent=\"%{User-Agent}i\"" security_combined
CustomLog logs/security_access.log security_combined
If Apache is behind a reverse proxy or load balancer, make sure headers such as X-Forwarded-For and
X-Real-IP are handled only from trusted proxy sources.
NGINX Web Server Logging
NGINX can also be configured to log investigation-friendly details.
log_format security_log '$time_iso8601 ' 'src_ip=$remote_addr ' 'src_port=$remote_port ' 'dst_ip=$server_addr ' 'dst_port=$server_port ' 'method=$request_method ' 'uri="$request_uri" ' 'status=$status ' 'bytes=$body_bytes_sent ' 'referer="$http_referer" ' 'user_agent="$http_user_agent"'; access_log /var/log/nginx/security_access.log security_log;
This captures time, source IP, source port, destination IP, destination port, HTTP method, URI, status code, and user agent.
Mail, DNS, and RADIUS Server Logging
Mail servers should log timestamp, source IP, source port, destination IP, destination port, username, authentication result, sender, recipient, message ID, and TLS status.
DNS servers should log timestamp, source IP, source port, destination IP, destination port, query name, query type, response code, and protocol.
RADIUS servers should log timestamp, username, NAS IP address, calling station ID, framed IP address, authentication result, session ID, source IP, source port, destination IP, and destination port.
Cloud Environments: AWS, Azure, and Google Cloud
If your systems run in cloud environments, you must enable proper network logging. Useful sources include AWS VPC Flow Logs, Azure Network Security Group Flow Logs, Google Cloud VPC Flow Logs, load balancer access logs, cloud firewall logs, WAF logs, CDN logs, and API gateway logs.
Cloud logging is often not enabled by default for all services. You must intentionally enable it and define a suitable retention period.
Dynamic IP Addresses and DNS
Some organizations use dynamic public IP addresses with DNS names. In this case, investigation becomes more difficult unless historical DNS and IP records are maintained.
DNS name Resolved public IP Date and time of change Service provider Device using the IP
If your public IP changes frequently, you should also log your own public IP periodically. This helps prove which IP was used by your organization at a specific time.
IPv6 Can Make Investigation Easier
IPv6 provides a much larger address space than IPv4. In many IPv6 deployments, devices can receive globally unique addresses without requiring NAT.
This can make investigation easier because the source IPv6 address may directly identify a customer, device, or network segment more clearly than shared IPv4 with CGNAT.
However, IPv6 does not remove the need for logging. You still need timestamp, source IPv6 address, source port, destination IPv6 address, and destination port.
Minimum Logging Checklist
- Incident date and time
- Timezone
- Source IP address
- Source port
- Destination IP address
- Destination port
- Protocol
- Service or application involved
- Firewall action
- NAT translation details
- Web, mail, DNS, and application logs
- User account involved, if applicable
- Public IP ownership at that time
Practical Example
A weak log may show:
203.0.113.xxx failed login for admin
A strong investigation-ready log should show:
Time: 2026-05-10 14:35:22 +0530 Source IP: 203.0.113.xxx Source Port: 51432 Destination IP: 198.51.100.xxx Destination Port: 443 Protocol: TCP URL: /login.php Method: POST Username attempted: admin Result: Failed login User-Agent: Mozilla/5.0 Firewall rule: Allowed HTTPS
Common Mistakes Organizations Make
- Logs are not enabled.
- Logs do not include source port.
- Devices are not synced with NTP.
- Timezone is unclear.
- Logs are overwritten too quickly.
- Firewall NAT logs are missing.
- Servers are behind proxies but real client IP is not logged.
- Cloud flow logs are disabled.
- Only application logs are collected.
- No centralized log storage exists.
- No incident response process is defined.
Final Recommendation
Cybersecurity is not only about blocking attacks. It is also about being ready to investigate when something goes wrong.
“How did this happen?”
It is also:
“Do we have enough evidence to prove what happened?”
Start today by reviewing your web server logs, firewall logs, cloud logs, NAT logs, DNS logs, mail logs, and time synchronization. Security breaches may be unavoidable in some cases, but poor investigation readiness is avoidable.
Disclaimer: This article is for general cybersecurity awareness and technical guidance. For legal or regulatory investigations, always consult your organization’s legal team, compliance team, ISP, cloud provider, or relevant law enforcement authority.