Computers and networks

Imagine opening a library’s website on your phone. A program runs, a name is resolved, messages cross a network, and another program decides which information to return. These are separate layers. Understanding them makes security explanations clearer even if you never use a command-line tool.

A process has a security context

A program stored on disk is a file. A process is an instance of a running program, with memory, threads, and references to resources. Several processes can run the same program.

The operating system associates execution with a security context: identities, groups, privileges, and restrictions. A friendly account name does not describe all that authority. An application may also maintain its own user identity, separate from the operating-system account running its service.

Opening a file creates a continuing reference

A handle, or a file descriptor on Unix-like systems, refers to an opened resource. Many permissions are checked when access is established. Later operations can use the already-open reference, subject to its granted access and other applicable checks.

Changing a pathname’s permissions does not universally revoke every existing handle. Nor does every read repeat the original pathname authorization check. Exact behavior depends on the operating system, object, operation, and policy. This is why defenders review both who may open a resource and what existing processes can continue to do.

DNS contains more than addresses

DNS organizes names and records. A and AAAA records identify IPv4 and IPv6 addresses; MX identifies mail exchangers; CNAME expresses an alias; TXT carries text used for several purposes. Not every DNS answer is an address.

A name can have several addresses. Different resolvers or network locations can receive different answers, and cached answers can persist until their permitted lifetime ends. An IP address is a routing destination in context, not permanent proof of machine identity or ownership. Keep the service name, address, time, and observation point together.

Transports and ports

TCP provides an ordered byte stream, handling retransmission and congestion as part of its operation. A connection can still fail; reliability does not promise that an unavailable peer eventually responds. UDP sends datagrams without transport-level delivery or ordering guarantees. Applications can add those features above UDP.

TCP and UDP have separate port spaces. A service using one does not establish that the same number is active on the other. Ports are not guaranteed application labels: conventional numbers are useful hints, while proxies and shared listeners can complicate the mapping to processes.

States describe observations

An open classification indicates behavior consistent with an accepting service for the method used. It need not mean a full handshake completed. Closed usually indicates no accepting service for that transport and observation. Filtered means the method could not establish an open or closed result because of filtering evidence, which can include explicit rejection or silence.

No reply alone has several possible causes, especially with UDP. Results depend on method, network position, and time. None of these labels establishes vulnerability, safety, or permission to test.

EXPLORE THE CONCEPT

How much can this observation tell you?

These are fictional observations, not requests sent to a real system.

A TCP port is reported open

The observation is consistent with a service accepting TCP connections. Some methods infer this without completing a connection. It does not identify every process detail or demonstrate a vulnerability.

No UDP response arrives

The service may not reply to that message, or traffic or replies may have been lost or filtered. Silence alone cannot decide which explanation is correct.

A filtered classification

The method could not determine an open or closed state because of filtering evidence. This may follow silence or explicit rejection, depending on the method and response.

A simplified learning model. It connects to no systems and uses no real data.

HTTP adds application meaning

HTTP describes requests and responses. GET requests retrieval rather than an intended state change; incidental logging is still compatible with its safe semantics. Status codes report outcomes, but do not prove that the correct person received the correct record.

HTTPS protects HTTP communication in transit and authenticates the server under the client’s trust rules. It does not guarantee truthful content or correct application permissions. HTTP/3 uses QUIC over UDP with integrated TLS, showing why an application protocol and its transport are different ideas.

For the library app, a complete explanation names the process, destination, transport, and application decision. Practice with the fictional model here; any activity against an external system follows the owner’s or provider’s permission.

Work through a complete library visit

Maya opens the fictional library page and searches for a book. First, the browser needs working memory and operating-system access to its network facilities. It obtains address information for the service name, then the device selects a route toward a destination. A local gateway can forward traffic beyond the current network. That gateway and a DNS resolver may live in the same home router, but they perform different jobs.

Suppose the public catalog loads, while Maya’s renewal is refused because another reader has reserved the book. Connectivity worked and the application applied a business rule. Changing the Wi-Fi password would not change that rule. Now suppose the name resolves but no response arrives: a route, policy, service outage, or return-path problem remains possible. The observation does not identify which one occurred.

PredictThe phone can display yesterday’s cached opening hours while offline. Does that prove the server is reachable now?

No. A stored response can be displayed without a new network exchange. Distinguish locally available information from a fresh response before drawing a conclusion about current availability.

Follow the two threads

Study data, memory, and execution to understand the program on the phone. Then follow names, addresses, and ports to understand how its request reaches another program. These are complementary explanations: one locates execution and authority; the other separates the decisions that move communication.