WEB / WEB-02.03

Ports, sockets and firewalls

IP describes a path toward a host interface; ports, sockets and firewalls identify the transport endpoint and its conditions.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

TCP + listener

TCP endpoint condition ready
Tuple is 192.0.2.10:51000 → 198.51.100.200:443. Listener presence is known in the fixture; no wire handshake or application response is shown.
Client endpoint
TCP new flow · endpoint condition selected
Transit firewall
Policy not yet evaluated
Server endpoint
TCP listener present · no traffic received
Firewall observed outbound traffic
Arrival at the transit policy point completed. NEW is observer context, not proof of TCP establishment.
Client endpoint
TCP summary sent to firewall
Transit firewall
Received: outbound / NEW / TCP / dst 443
Server endpoint
TCP listener present · no traffic received
Local WEB_OUT policy match
Outbound NEW TCP destination 443 matches the toy rule: allow. This local decision is not delivery to the server.
Client endpoint
Client tuple 192.0.2.10:51000
Transit firewall
WEB_OUT → allow
Server endpoint
TCP listener present · no traffic received
Allowed traffic reached the server
The server observer now received traffic. Firewall allow and endpoint delivery are separate steps; no application body is represented.
Client endpoint
Client tuple 192.0.2.10:51000
Transit firewall
WEB_OUT allow · forwarded
Server endpoint
TCP traffic received · listener present
Matching listener evaluated locally
With a known matching listener, establishment is possible. This summary is not a full handshake, actual creation of accepted socket c1, or TLS/HTTP success.
Client endpoint
Application response outcome unknown
Transit firewall
WEB_OUT allow · forwarded
Server endpoint
Listener present · establishment possible

TCP / no listener

Listener condition changed
Tuple and policy match NORMAL, but this variant has no matching listener in the fixture. No real service shutdown or OS API is executed.
Client endpoint
TCP 192.0.2.10:51000 → 198.51.100.200:443
Transit firewall
Policy not yet evaluated
Server endpoint
Matching listener absent · no traffic received
TCP summary reached the firewall
The firewall observer received outbound NEW TCP 443 context. Listener presence is not the same observation as firewall verdict.
Client endpoint
TCP summary sent
Transit firewall
Received: outbound / NEW / TCP / dst 443
Server endpoint
Matching listener absent · no traffic received
Same WEB_OUT rule allows
Rule conditions match normal, so the result is allow. This decision does not create a listener.
Client endpoint
Client tuple unchanged
Transit firewall
WEB_OUT → allow
Server endpoint
Matching listener absent · no traffic received
TCP traffic reached the endpoint
Filtering did not prevent this delivery. Absence of a matching listener is a separate local condition.
Client endpoint
Client tuple unchanged
Transit firewall
WEB_OUT allow · forwarded
Server endpoint
TCP traffic received · matching listener absent
Connection not established
Fixture-known listener absence prevents normal establishment. TCP refusal and OS reporting details are omitted; this is not an observed ECONNREFUSED result.
Client endpoint
Normal connection not established
Transit firewall
Allow decision remains valid
Server endpoint
Listener absent · not-established

UDP 443

Transport is UDP instead of TCP
The port number remains 443 but the transport namespace changes. A TCP listener is not a UDP service.
Client endpoint
UDP 192.0.2.10:51000 → 198.51.100.200:443
Transit firewall
Policy not yet evaluated
Server endpoint
TCP listener present · no UDP traffic received
UDP datagram reached the firewall
The toy observer treats this new datagram context as NEW. No TCP handshake is drawn for UDP.
Client endpoint
UDP summary sent
Transit firewall
Received: outbound / NEW / UDP / dst 443
Server endpoint
TCP listener present · no UDP traffic received
Local default deny
WEB_OUT requires TCP and RETURN conditions are absent. Default deny prevents transfer to the server. Silence is not evidence about an external target’s state.
Client endpoint
Datagram not forwarded
Transit firewall
DEFAULT → deny · no forward
Server endpoint
TCP listener present · no UDP traffic received

RETURN allow

Existing flow is a separate fixture condition
The c1 reverse tuple is 198.51.100.200:443 → 192.0.2.10:51000. The observer’s known ESTABLISHED context is an explicit initial condition.
Client endpoint
Existing c1 · no return summary received
Transit firewall
Known c1 context · return not yet arrived
Server endpoint
Reverse TCP summary ready
Reverse flow reached the firewall
The observer relates the exact reverse tuple to its own known-flow context. It does not trust a client-supplied state label.
Client endpoint
Existing c1 · no return summary received
Transit firewall
Received: inbound / ESTABLISHED / known c1
Server endpoint
Reverse TCP summary sent
Local RETURN match
Known reverse flow and observer ESTABLISHED state match RETURN: allow. New unsolicited inbound NEW traffic is outside these conditions.
Client endpoint
Existing c1 · no return summary received
Transit firewall
RETURN → allow
Server endpoint
Reverse TCP summary sent
Existing client endpoint received the reply
Delivery of the reverse tuple to 192.0.2.10:51000 completed. This synthetic transport summary is neither HTTP success nor user authorization verdict.
Client endpoint
c1 return received: dst 192.0.2.10:51000
Transit firewall
RETURN allow · forwarded
Server endpoint
Reverse TCP summary sent

ACTORS · STATE · DATA FLOW

A port number alone is not an endpoint

TCP and UDP headers contain 16-bit source and destination port fields, giving a numeric field range of 0–65535. That range does not mean every value has identical application allocation semantics. TCP 443 and UDP 443 are distinct transport contexts. IP itself does not contain these TCP/UDP port fields; identify the carried transport too.

Our client uses TCP from 192.0.2.10:51000 to 198.51.100.200:443. The client port is a synthetic selection, not a universal OS ephemeral range. Port 443 suggests an HTTPS convention but proves neither the running process, TLS identity nor resource permission. Read address, transport and port together to identify an endpoint.

A socket is an OS object; a connection joins endpoints

A network socket is an object an application uses through the OS communication interface. Equating it with a port omits address family, transport and local address scope. A TCP connection is distinguished by the local/remote address-port pair in its transport context. Multiple clients can connect to the same server port.

The artifact lists web-listener as LISTEN at 198.51.100.200:443. Separate accepted connections c1 and c2 share that local endpoint but have peers 192.0.2.10:51000 and 192.0.2.20:52000. These are invented field summaries rather than Linux command output or memory dumps. A listener record does not establish an accepted connection or HTTP response.

Bind, listen and accept have different roles

In the Linux socket API, bind() assigns a local address, listen() marks a suitable connection-oriented socket as passive, and accept() returns another socket for a new connection. Our normal TCP service uses those roles. UDP datagrams should not be forced into the same listener/accepted-connection model.

Binding scope changes access expectations. Address 127.0.0.1 denotes loopback, while 0.0.0.0 means any local address for IPv4 socket binding. Wildcard binding does not guarantee Internet reachability: interfaces, routes, network namespaces and filtering still matter. IPv6 wildcard and dual-stack behavior require the platform settings rather than an assumed identical rule.

Which policy point makes the firewall decision?

Packet filtering can examine addresses, transport, ports, direction and interfaces. Stateful filtering also uses context maintained by the observing firewall. FORWARD inspects transit traffic not addressed to the firewall host; INPUT handles traffic to that host and OUTPUT its locally generated traffic. Chain scope changes what a rule protects.

The toy policy allows outbound NEW TCP to destination port 443 through WEB_OUT. RETURN permits the reverse direction of a known flow with observerState ESTABLISHED; other conditions default to deny. These are fixture fields, not kernel or nftables syntax. UDP 443 does not match the TCP rule. State is derived by the observer rather than trusted from a client assertion.

Allowed, listening and successful are separate outcomes

Firewall allow describes passage at that policy point. A normal TCP connection cannot be established without a matching listener; even with one, routing, capacity and later layers can change the result. The no-listener branch has fixture-known absence and shows failure to establish. It generates no claimed OS error code or captured RST.

Connection-tracking ESTABLISHED and a TCP endpoint state are different observations. Neither should be promoted directly to proof of an HTTP response. Stateful UDP observations do not imply a TCP handshake. A return rule needs its flow, direction and policy conditions; a state label does not provide application authorization.

Read every scenario without motion

No listener

A numeric port is not a service
NO_LISTENER requests outbound NEW TCP destinationPort=443. A port convention proves neither a listener nor TLS/application identity.
Endpoint intent
TCP 443
Forward gate
No rule
Service boundary
No service proof
The rule was read with all conditions
WEB_OUT requires outbound direction, NEW observerState, TCP transport and destinationPort=443 together. One matching field is not a matching rule.
Endpoint intent
TCP 443
Forward gate
WEB_OUT match
Service boundary
No service proof
The forwarding verdict was selected
expectedDecision=allow and expectedRule=WEB_OUT. Abstract FORWARD allow does not say that the endpoint accepted a connection.
Endpoint intent
TCP 443
Forward gate
ALLOW / WEB_OUT
Service boundary
No service proof
The listener condition remains separate
listenerPresent=false means connectionOutcome=not-established. Firewall allow and an absent application endpoint can both be true.
Endpoint intent
TCP 443
Forward gate
ALLOW / WEB_OUT
Service boundary
No listener / not-established
Silence does not identify one cause
A browser seeing no response cannot distinguish these conditions by itself. The fixed fixture supplies the cause; actual review needs separate rule verdict and listener evidence.
Endpoint intent
No response ≠ single cause
Forward gate
ALLOW / WEB_OUT
Service boundary
No listener / not-established
Authority stayed at the higher layer
Even a possible connection needs separate authentication and object permission. This abstract transit policy is neither a kernel firewall API, TLS handshake nor an actual socket attempt.
Endpoint intent
No response ≠ single cause
Forward gate
ALLOW / WEB_OUT
Service boundary
UNKNOWN: application permission

Same port, UDP

A numeric port is not a service
UDP_SAME_NUMBER carries destinationPort=443; the same number in another transport namespace identifies a different endpoint.
Endpoint intent
UDP 443
Forward gate
No rule
Service boundary
No service proof
The rule was read with all conditions
WEB_OUT requires outbound direction, NEW observerState, TCP transport and destinationPort=443 together. One matching field is not a matching rule.
Endpoint intent
UDP 443
Forward gate
WEB_OUT transport mismatch
Service boundary
No service proof
The forwarding verdict was selected
expectedDecision=deny and expectedRule=DEFAULT. Permission for TCP 443 is not imported into UDP; no receiver-delivery result is asserted.
Endpoint intent
UDP 443
Forward gate
DENY / DEFAULT
Service boundary
No service proof
The listener condition remains separate
listenerPresent=false is a supplied condition of this UDP case. Policy denial already marks the boundary; no server-request-received state is invented.
Endpoint intent
UDP 443
Forward gate
DENY / DEFAULT
Service boundary
Not forwarded
Silence does not identify one cause
A browser seeing no response cannot distinguish these conditions by itself. The fixed fixture supplies the cause; actual review needs separate rule verdict and listener evidence.
Endpoint intent
No response ≠ single cause
Forward gate
DENY / DEFAULT
Service boundary
Not forwarded
Authority stayed at the higher layer
Even a possible connection needs separate authentication and object permission. This abstract transit policy is neither a kernel firewall API, TLS handshake nor an actual socket attempt.
Endpoint intent
No response ≠ single cause
Forward gate
DENY / DEFAULT
Service boundary
UNKNOWN: application permission

ASSUMPTION · BOUNDARY · CONTROL

Broken assumption: a permitted number is a trusted service

Allowing TCP 443 may assume the endpoint is the intended web service. Correct binding and transport, deployment evidence, and application/TLS controls support that assumption. A changed process or interface scope can give the same number a different meaning.

Keep the control impact precise: a port convention does not prove resource access rights, although overly broad traffic policy may change reachability. This lesson compares local fixture conditions without endpoint discovery or service-probing workflows.

Broken assumption: state and direction are interchangeable

RETURN requires the reverse tuple of a known flow and state maintained by the relevant observer. Matching only a destination port or the word ESTABLISHED loses that relationship. An observer on an asymmetric path may lack context; implementations and policies need not all respond identically.

A deny observation needs rule scope and the correct observation point. Stateful allow does not replace user authentication or object ownership checks. The lesson rules are a decision model rather than configuration snippets for a network product.

Broken assumption: silence identifies one cause

In the no-listener branch, firewall allow and listener absence are both true. In the filtered branch, listener existence does not show that traffic reached it. Without telemetry, no response cannot distinguish the two.

Use this distinction for root-cause reasoning: compare known inert fixture conditions and name the missing evidence. It requires neither external connection attempts nor timing fingerprints.

Read every scenario without motion

Return scope

Listener and connection were separated
web-listener is TCP LISTEN at 198.51.100.200:443; c1 and c2 share that local port but have distinct remote IP/ports and ESTABLISHED endpoint records.
Endpoint inventory
One listener / two tuples
Policy expectation
No rule observation
Scope review
No scope review
Observer state is not endpoint state
The RETURN row expects allow for inbound, observerState=ESTABLISHED and knownFlow=true. In a running system the transit firewall produces observer state, while endpointState belongs to the endpoint socket. Both fields here are supplied in a synthetic ledger, not collected from one runtime producer.
Endpoint inventory
One listener / two tuples
Policy expectation
RETURN expected allow
Scope review
No scope review
The reverse-flow condition was checked
The known reverse tuple is 198.51.100.200:443 → 192.0.2.10:51000. Neither a port nor the word ESTABLISHED substitutes for the flow relationship.
Endpoint inventory
One listener / two tuples
Policy expectation
RETURN expected allow
Scope review
Tuple + direction + knownFlow
The verdict claim was bounded
The RETURN matrix row supplies expectedRule=RETURN and expectedDecision=allow. Its model conditions agree with that expectation; the row is not a measured firewall verdict or packet acceptance. Runtime verification needs a separate transit-policy record for the same tuple and direction.
Endpoint inventory
One listener / two tuples
Policy expectation
Expected: RETURN / allow
Scope review
Tuple + direction + knownFlow
The ordinary negative control is preserved
UNSOLICITED inbound NEW with knownFlow=false expects DEFAULT deny. It is not confused with RETURN allowance; a new inbound flow is outside that rule.
Endpoint inventory
UNSOLICITED → DEFAULT deny
Policy expectation
Expected: RETURN / allow
Scope review
Tuple + direction + knownFlow
Regression retains separate layers
Known RETURN allowance and unsolicited/UDP denials are distinct expectations. NO_LISTENER preserves allow-but-not-established. This control matrix supplies no measured filtering or application success; each layer needs its own observation.
Endpoint inventory
UNSOLICITED → DEFAULT deny
Policy expectation
Expected: RETURN / allow
Scope review
Policy expectations distinct; runtime unknown

Verdict absent

Listener and connection were separated
web-listener is TCP LISTEN at 198.51.100.200:443; c1 and c2 share that local port but have distinct remote IP/ports and ESTABLISHED endpoint records.
Endpoint inventory
One listener / two tuples
Policy expectation
No rule observation
Scope review
No scope review
Observer state is not endpoint state
The RETURN row expects allow for inbound, observerState=ESTABLISHED and knownFlow=true. In a running system the transit firewall produces observer state, while endpointState belongs to the endpoint socket. Both fields here are supplied in a synthetic ledger, not collected from one runtime producer.
Endpoint inventory
One listener / two tuples
Policy expectation
RETURN expected allow
Scope review
No scope review
The reverse-flow condition was checked
The known reverse tuple is 198.51.100.200:443 → 192.0.2.10:51000. Neither a port nor the word ESTABLISHED substitutes for the flow relationship.
Endpoint inventory
One listener / two tuples
Policy expectation
RETURN expected allow
Scope review
Tuple + direction + knownFlow
The verdict claim was bounded
This review copy lacks policy observation. expectedRule=RETURN remains an expectation; not seeing a denial is not observing an allow.
Endpoint inventory
One listener / two tuples
Policy expectation
UNKNOWN: observed verdict
Scope review
Tuple + direction + knownFlow
The ordinary negative control is preserved
UNSOLICITED inbound NEW with knownFlow=false expects DEFAULT deny. It is not confused with RETURN allowance; a new inbound flow is outside that rule.
Endpoint inventory
UNSOLICITED → DEFAULT deny
Policy expectation
UNKNOWN: observed verdict
Scope review
Tuple + direction + knownFlow
Regression retains separate layers
Listener inventory and the expected return rule are known, but observed verdict remains UNKNOWN. No cause of service failure is chosen without policy evidence.
Endpoint inventory
UNSOLICITED → DEFAULT deny
Policy expectation
UNKNOWN: observed verdict
Scope review
UNKNOWN: filter outcome

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Connect listener, flow and application evidence

Listener inventory identifies a process’s waiting local endpoint. A connection record shows both peer tuples and the endpoint’s own state. Firewall observations identify a verdict at a policy point. Application logs separately record requests and permission outcomes. One observation cannot stand in for all four.

The fixture’s c1/c2 demonstrate two connections sharing a server port. Real correlation needs time, namespace/interface and pre/post NAT tuple scope. Consult each product schema; ruleId and observerState here are not asserted to be actual log fields.

Use positive and negative baselines together

The normal case permits outbound NEW TCP 443 by WEB_OUT with a matching listener, making establishment possible. UDP 443 does not match. Unsolicited inbound NEW defaults to deny. A known reverse ESTABLISHED flow is allowed by RETURN. These selected outcomes are not an inventory of all product behavior.

Allow without a listener identifies a missing endpoint condition rather than firewall malfunction. A filtered branch must not update the server to request-received state. Absence of a deny log is not allow evidence; record logging, sampling and observation limits.

Verify regression intent through the fields

Review transport, direction, state provenance and exact flow conditions together. A TCP allowance must not accidentally permit UDP; relaxing a return rule must not admit new inbound traffic. A bind change should preserve the intended local address scope.

Keep the conclusion within the fields actually observed. Consistent tuples and expectedDecision values do not prove that a running firewall made that decision. Obtain a record from the transit policy point; listener and accepted-socket state need endpoint evidence, and TLS/HTTP outcomes need their own layer observations. Do not merge these into one success label without a matching operation and observation time.

NOW APPLY IT TO THE CASE

Where do firewall allowance and service acceptance differ?

The abstract FORWARD policy can allow outbound TCP port 443. The connection still cannot be established without a matching listener. A known return flow and a new inbound flow have different conditions.

Which network path carries the case response? Evaluate byte, IP-route, socket and firewall evidence separately from the application returning the correct book.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

One listener, two connections, five policy cases

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "scope": "Abstract transit/FORWARD policy; custom fields, not a kernel API or capture. NAT absent in this fixture.",
  "listeners": [
    {
      "id": "web-listener",
      "family": "IPv4",
      "transport": "TCP",
      "localIp": "198.51.100.200",
      "localPort": 443,
      "endpointState": "LISTEN"
    }
  ],
  "connections": [
    {
      "id": "c1",
      "family": "IPv4",
      "transport": "TCP",
      "localIp": "198.51.100.200",
      "localPort": 443,
      "remoteIp": "192.0.2.10",
      "remotePort": 51000,
      "endpointState": "ESTABLISHED"
    },
    {
      "id": "c2",
      "family": "IPv4",
      "transport": "TCP",
      "localIp": "198.51.100.200",
      "localPort": 443,
      "remoteIp": "192.0.2.20",
      "remotePort": 52000,
      "endpointState": "ESTABLISHED"
    }
  ],
  "abstractPolicy": {
    "defaultDecision": "deny",
    "rules": [
      {
        "id": "RETURN",
        "conditions": {
          "direction": "inbound",
          "observerState": "ESTABLISHED",
          "knownFlow": true
        },
        "decision": "allow"
      },
      {
        "id": "WEB_OUT",
        "conditions": {
          "direction": "outbound",
          "observerState": "NEW",
          "transport": "TCP",
          "destinationPort": 443
        },
        "decision": "allow"
      }
    ]
  },
  "cases": [
    {
      "id": "NORMAL",
      "transport": "TCP",
      "sourceIp": "192.0.2.10",
      "sourcePort": 51000,
      "destinationIp": "198.51.100.200",
      "destinationPort": 443,
      "direction": "outbound",
      "observerState": "NEW",
      "knownFlow": false,
      "listenerPresent": true,
      "expectedDecision": "allow",
      "expectedRule": "WEB_OUT",
      "connectionOutcome": "possible"
    },
    {
      "id": "RETURN",
      "transport": "TCP",
      "sourceIp": "198.51.100.200",
      "sourcePort": 443,
      "destinationIp": "192.0.2.10",
      "destinationPort": 51000,
      "direction": "inbound",
      "observerState": "ESTABLISHED",
      "knownFlow": true,
      "listenerPresent": null,
      "expectedDecision": "allow",
      "expectedRule": "RETURN",
      "connectionOutcome": "existing-flow"
    },
    {
      "id": "UDP_SAME_NUMBER",
      "transport": "UDP",
      "sourceIp": "192.0.2.10",
      "sourcePort": 51000,
      "destinationIp": "198.51.100.200",
      "destinationPort": 443,
      "direction": "outbound",
      "observerState": "NEW",
      "knownFlow": false,
      "listenerPresent": false,
      "expectedDecision": "deny",
      "expectedRule": "DEFAULT",
      "connectionOutcome": "not-forwarded"
    },
    {
      "id": "UNSOLICITED",
      "transport": "TCP",
      "sourceIp": "198.51.100.200",
      "sourcePort": 443,
      "destinationIp": "192.0.2.10",
      "destinationPort": 51000,
      "direction": "inbound",
      "observerState": "NEW",
      "knownFlow": false,
      "listenerPresent": null,
      "expectedDecision": "deny",
      "expectedRule": "DEFAULT",
      "connectionOutcome": "not-forwarded"
    },
    {
      "id": "NO_LISTENER",
      "transport": "TCP",
      "sourceIp": "192.0.2.10",
      "sourcePort": 51000,
      "destinationIp": "198.51.100.200",
      "destinationPort": 443,
      "direction": "outbound",
      "observerState": "NEW",
      "knownFlow": false,
      "listenerPresent": false,
      "expectedDecision": "allow",
      "expectedRule": "WEB_OUT",
      "connectionOutcome": "not-established"
    }
  ]
}

transport + local/remote IP/port: Tuple distinguishing peer endpoints and transport namespace.
endpointState: Synthetic endpoint state, distinct from firewall conntrack state.
direction / observerState / knownFlow: Toy firewall conditions; peer assertions are not trusted state.
expectedRule / expectedDecision: Abstract rule match and transit policy decision.
listenerPresent / connectionOutcome: Endpoint condition separate from allow; possible does not claim an observed handshake.

Inert condition ledger, not live sockets, nftables configuration, wire captures or error codes. Handshake details, timeouts/retries, related flows, policy-order variants and UDP tracking are omitted.

Two reality checks

Allowing port 443 proves the web application is secure and will respond.

Allow is a decision at one policy point. Transport, listener, path, TLS and application permissions need separate conditions and evidence.

A server port can have only one connection.

A listener can accept multiple connections at one local endpoint; remote tuples distinguish their conversations.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The firewall allows the NO_LISTENER case. Is connection establishment guaranteed?

No; listenerPresent=false and outcome is not-established.
Yes; allow means connection success.

Read the explained answer

No; listenerPresent=false and outcome is not-established. — WEB_OUT permits forwarding; it supplies neither remote listening nor application success.

Two ESTABLISHED records use the same local port. Are they one connection?

Selected lesson artifact fields; teaching example

connections[0]: {"id":"c1","family":"IPv4","transport":"TCP","localIp":"198.51.100.200","localPort":443,"remoteIp":"192.0.2.10","remotePort":51000,"endpointState":"ESTABLISHED"}
connections[1]: {"id":"c2","family":"IPv4","transport":"TCP","localIp":"198.51.100.200","localPort":443,"remoteIp":"192.0.2.20","remotePort":52000,"endpointState":"ESTABLISHED"}

No; the remote tuples differ.
Yes; local 443 merges all connections.

Read the explained answer

No; the remote tuples differ. — Connection identity is not one port number; local/remote endpoints and transport are considered together.

Why is UDP_SAME_NUMBER not treated as the same endpoint as the TCP web listener?

Read the explained answer

Port 443 does not merge TCP/UDP namespaces. The fixture defines only a TCP listener and TCP WEB_OUT rule; the UDP branch receives default deny. This outcome describes the selected policy, not a universal UDP prohibition.

□ I included transport in endpoint identity.

□ I tied deny to this policy.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

RFC 9293 — TCP2.2 Key TCP Concepts · 3.1 Header Format · 3.2 Terminology · 3.3.2 State Machine Overview · 3.9.1 The User/TCP Interface
RFC 768 — UDPFormat · Fields
Linux man-pages — socket(7)DESCRIPTION · Socket-layer functions
Linux man-pages — bind(2)DESCRIPTION
Linux man-pages — listen(2)DESCRIPTION
Linux man-pages — ip(7)Address format · Special and reserved addresses: INADDR_LOOPBACK and INADDR_ANY
Red Hat Enterprise Linux 9 — nftables2.7.2 Security requirements to the firewall script · 2.7.4 Writing and activating the nftables script: INPUT/OUTPUT/FORWARD and ct state
RFC 5737 — Documentation IPv43 Documentation Address Blocks

YOUR NOTES / THIS BROWSER

Ports, sockets and firewalls

1. Core · Mechanism

TCP + listener

TCP / no listener

UDP 443

RETURN allow

A port number alone is not an endpoint

A socket is an OS object; a connection joins endpoints

Bind, listen and accept have different roles

Which policy point makes the firewall decision?

Allowed, listening and successful are separate outcomes

2. Red · Trust & Impact

No listener

Same port, UDP

Broken assumption: a permitted number is a trusted service

Broken assumption: state and direction are interchangeable

Broken assumption: silence identifies one cause

3. Blue · Secure development & defense

Return scope

Verdict absent

Connect listener, flow and application evidence

Use positive and negative baselines together

Verify regression intent through the fields

Where do firewall allowance and service acceptance differ?

Two reality checks

The firewall allows the NO_LISTENER case. Is connection establishment guaranteed?

Two ESTABLISHED records use the same local port. Are they one connection?

Why is UDP_SAME_NUMBER not treated as the same endpoint as the TCP web listener?

Sources and scope