Passive OS fingerprinting is the analysis of TCP/IP stack attributes—such as initial Time-to-Live (TTL), TCP window size, Don't Fragment (DF) flags, and TCP option ordering—in passively observed packets to identify the operating system of a connecting host. Unlike active fingerprinting tools like Nmap, this method generates zero additional network traffic, making it invisible to the target and undetectable by intrusion detection systems. The technique relies on the fact that different operating systems implement the TCP/IP specification with subtle, consistent variations that serve as a unique signature.
Glossary
Passive OS Fingerprinting

What is Passive OS Fingerprinting?
Passive OS fingerprinting is a network reconnaissance technique that identifies a remote host's operating system by silently observing the unique characteristics of its TCP/IP stack implementation without sending any probing packets to the target.
Security architects and platform engineers leverage passive fingerprinting within bot management and AI crawler identification pipelines to distinguish legitimate browser traffic from automated scripts. By cross-referencing the observed OS signature against the declared User-Agent string, engineers can detect mismatches—such as a Python script claiming to be Chrome on Windows—that indicate headless browser or scraping activity. Tools like p0f and Zeek integrate this analysis at the network edge, feeding bot score calculations and enabling preemptive blocking of datacenter-originated crawlers.
Key TCP/IP Attributes Analyzed
Passive OS fingerprinting examines specific fields within observed TCP/IP packets to infer the operating system of a remote host without sending any probe traffic. The following attributes form the core signature analyzed by tools like p0f and Wireshark.
Initial Time-to-Live (TTL)
The TTL value set in the IP header of the first packet from a host. Different operating systems use distinct default starting values.
- Linux/Android: Typically starts at 64
- Windows: Typically starts at 128
- Cisco/Solaris: Typically starts at 255
By observing the TTL of a received packet and accounting for the number of network hops, you can estimate the original OS. A packet arriving with a TTL of 52 likely originated from a Linux host roughly 12 hops away.
TCP Window Size
The TCP receive window advertised in the SYN or SYN-ACK packet indicates the buffer space the host is willing to accept. This value is highly OS-specific and often remains consistent across versions.
- Windows: Often uses a window size that is a multiple of MSS (Maximum Segment Size), or specific values like 65535
- Linux: Tends to use multiples like 29200 or 28960
- macOS/iOS: Commonly advertises 65535
This field is a cornerstone of passive fingerprinting because it is rarely modified by user applications.
Don't Fragment (DF) Flag
The DF bit in the IP header controls whether a packet can be fragmented by routers along the path. The default setting of this flag is a strong OS indicator.
- Windows: Sets the DF flag to 1 (on) by default for outbound TCP SYN packets
- Linux: Typically sets the DF flag to 0 (off), allowing fragmentation
- Network Devices: Often mirror the behavior of their kernel (e.g., Juniper based on FreeBSD)
Combined with TTL and Window Size, the DF flag helps disambiguate signatures between Windows and Linux hosts.
TCP Options Order & Values
The specific sequence, type, and values of TCP options negotiated in the SYN packet create a unique fingerprint.
- MSS (Maximum Segment Size): The value itself can indicate the underlying network interface MTU
- Window Scaling: The multiplier factor (e.g., 7 or 8) is OS-dependent
- SACK Permitted: Selective Acknowledgment support is standard on modern OSes
- NOP (No-Operation): The padding bytes used to align options vary in placement
- Timestamp: The format and frequency of TCP timestamps differ between kernels
The exact order—such as MSS, SACK, Timestamp, NOP, Window Scale—is a classic signature for specific Linux kernels.
IP Header ID Generation
The IP Identification field is a 16-bit value used to uniquely identify fragments of a datagram. The algorithm used to generate this ID differs by OS.
- Windows: Increments the ID by 1 for each packet, regardless of destination
- Linux: Tends to use a random or zero ID for non-fragmented traffic
- OpenBSD: Uses a randomized ID for security
A monotonically increasing ID pattern strongly suggests a Windows host, while random or zero IDs point toward Unix-like systems.
SYN Packet Size
The total length of the initial TCP SYN packet is a quick heuristic for OS identification. Because TCP options vary in length and count, the overall packet size is a reliable aggregate metric.
- Windows: Often sends a SYN packet of 52 bytes (options like MSS, NOP, Window Scale, NOP, NOP, SACK)
- Linux: Often sends a SYN packet of 60 bytes (includes Timestamp option)
- macOS: Typically sends a SYN packet of 64 bytes
This simple size check can immediately narrow down the OS family before deeper inspection.
Frequently Asked Questions
Explore the technical nuances of identifying remote operating systems through passive network traffic analysis, a critical technique for distinguishing legitimate user agents from spoofed AI crawler infrastructure.
Passive OS fingerprinting is a network surveillance technique that identifies a remote host's operating system by silently analyzing the distinct attributes of its TCP/IP stack implementation without sending any probe packets to the target. Unlike active fingerprinting tools like Nmap, which stimulate a response, passive methods observe live traffic flows—such as an incoming HTTP request from an AI crawler—to extract forensic signatures. The process relies on the fact that different operating systems (Linux, Windows, macOS) have unique default values for parameters like the Initial Time-to-Live (TTL) , TCP Window Size, and Don't Fragment (DF) bit behavior. By comparing these observed values against a signature database (such as the p0f fingerprint library), a network sensor can determine with high probability whether a connection originates from a Linux server in a data center or a genuine Windows 10 client, enabling precise bot detection without alerting the crawler.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Explore the core TCP/IP attributes and related identification techniques that form the foundation of passive operating system detection.
Initial Time-to-Live (TTL)
The starting TTL value set by the operating system's IP stack on outbound packets. This is a primary discriminant in passive fingerprinting.
- Linux/Unix: Typically starts at 64
- Windows: Typically starts at 128
- Cisco IOS: Typically starts at 255
By observing the TTL of a received packet and calculating the hops to the host, you can infer the originating OS.
TCP Window Size
The initial receive window size advertised in the TCP SYN or SYN-ACK packet. This value is highly OS-specific and often remains consistent across versions.
- Windows Server: Often 8192 or 65535
- Linux: Often 29200 or 28960 (multiples of MSS)
- macOS/iOS: Often 65535
This field is a critical component of the p0f fingerprinting signature.
Don't Fragment (DF) Flag
A single bit in the IP header that prohibits routers from fragmenting the packet. The default setting of this flag is a strong OS indicator.
- Windows: Sets DF flag on all outbound packets by default
- Linux: Typically does not set DF flag by default
- Network Devices: Often set DF for Path MTU Discovery
Combined with TTL and MSS, the DF flag helps distinguish between Windows and Linux hosts with high confidence.
Maximum Segment Size (MSS)
The largest amount of TCP data a host is willing to receive in a single segment, advertised during the TCP handshake. This value reflects the local MTU minus headers.
- Ethernet standard: 1460 bytes (1500 MTU - 40 bytes)
- PPPoE connections: Often 1452
- Tunneling/VPNs: Can be significantly lower
Anomalous MSS values can indicate a specific network configuration or a non-standard IP stack used by bots.
TCP Option Order & Values
The specific sequence, type, and values of TCP options (e.g., MSS, Window Scale, SACK Permitted, Timestamp) in the SYN packet form a unique signature.
- Option Order: The exact sequence is a strong fingerprint (e.g.,
MSS, NOP, WS, NOP, NOP, TS) - Timestamp Value: Some OSs initialize the timestamp to zero; others use a random value
- Window Scale Factor: The multiplier value varies by OS
Tools like p0f and Ettercap use these combined signatures to match against a database of known OS fingerprints.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us