4.9.3.2 - Firewalls, cryptography and malicious software

Packet filtering, proxies and stateful inspection

A firewall applies security rules to traffic crossing a boundary, permitting some communication and refusing other communication.

Packet filtering examines packet/header information such as source and destination IP addresses, protocol and ports against rules. A rule might allow incoming traffic to a public web service while denying another service. A stateless filter examines each packet without remembering the connection history. An allowed address or port does not prove that the payload is harmless.

A proxy firewall/server receives an application's request and makes a separate onward request on the client's behalf. This intermediates the exchange rather than simply passing the original packet unchanged. It can apply application-level rules, inspect requests where the protocol/content is visible, hide direct client access to an external server, or log activity. Inspection requires processing and adds overhead; a proxy cannot automatically read encrypted application content without appropriate termination or decryption.

Stateful inspection keeps a record of active connections and their state. Rules can allow a response associated with an authorised outgoing exchange while rejecting an unsolicited incoming attempt that otherwise looks similar. It combines packet/header checks with connection history. It does not turn a legitimate connection into proof that every message within it is safe.

For example, a staff computer requests a page from a remote server. A stateful firewall can recognise the returning traffic as belonging to that exchange. A separate unsolicited attempt to start a connection to the staff computer can be denied. A proxy may instead terminate the staff request and apply rules before opening its own server connection. These are different mechanisms and can be combined in one product.

Symmetric keys, asymmetric keys and exchange

Encryption protects the confidentiality of data by converting readable plaintext into ciphertext using a key and an algorithm.

With symmetric encryption, communicating parties use the same shared secret key to encrypt and decrypt. It is efficient for substantial data transfers, but the key must reach the intended parties securely. Sending the secret key beside the ciphertext in an observable unprotected channel defeats that protection.

With asymmetric encryption, each participant has a mathematically related public/private key pair. The public key may be distributed; the private key must remain secret. For confidentiality, a sender encrypts for the recipient using the recipient's public key, and only the corresponding private key should decrypt it. Public-key operations usually cost more processing than symmetric encryption, so many systems use asymmetric methods to establish or protect a shared session key and symmetric encryption for the data.

One conceptual key-exchange method is:

1. Obtain and authenticate the recipient's public key.
2. Generate a fresh random symmetric session key.
3. Encrypt that session key using the recipient's public key and send the encrypted result.
4. The recipient uses its private key to recover the session key; both sides can now use it for symmetric data encryption.

This illustrates public-key protection of a transferred key, not a claim that every modern secure protocol uses that exact method. Modern protocols can instead use authenticated key agreement to derive a shared secret without transmitting it. In either case, establishing whose key is being used is essential. If an attacker substitutes their own public key, encryption alone can securely send a secret to the wrong party.

Encryption is not the same as hashing. A hash is a fixed-size digest used in integrity/signature processes; it is not a reversible way to hide a message. Encryption also does not itself prove who created a message. Identity and integrity require appropriate authentication mechanisms.

Digital certificates and signatures

Digital certificates bind an identity to a public key, while digital signatures let a recipient check a signed message's integrity and origin under a key.

To obtain a certificate, an applicant generates a key pair, keeps the private key secret and submits the public key and identity/domain information to a certificate authority (CA). The CA checks the relevant claim according to its policy and issues a digitally signed certificate. A certificate includes the subject identity, public key, issuer and validity information. It does not publish the subject's private key.

A client receiving a server certificate checks the CA's signature using the issuer's public key, follows a chain to a trusted authority, checks validity and confirms that the certificate applies to the intended name. Relevant revocation status may also be checked. Trust in a root is established through the client's trusted-root configuration; merely receiving a certificate does not make it trusted. A valid domain certificate is not proof that the website's business is honest or that its content is harmless.

For a digital signature, the sender hashes the message and uses their private signing key in the signature algorithm to produce a signature associated with that digest. The recipient uses the sender's public key to verify the signature against the message's calculated digest. Altered data fails verification, as does a signature made with a different private key. Some elementary descriptions call this “encrypting the hash with the private key”; the general operation is signing, not confidentially encrypting the whole message.

Successful verification supports that the message is unchanged and was signed under the corresponding private key. Associating that key with the claimed person/server requires trustworthy identity evidence, such as an appropriate certificate. A compromised private key undermines that assurance. A signature can accompany a readable message, so it does not by itself provide confidentiality.

Certificates also use signatures: the CA signs the certificate's contents, allowing changes to its identity/key binding to be detected. The subject's private key remains with the subject; the CA uses its own private key to sign the certificate.

Malware, vulnerabilities and layered defence

Malicious software exploits weaknesses in code, configuration or user behaviour, and different forms spread in different ways.

A trojan need not self-replicate; its deception is the defining feature. A worm may spread automatically after its initial entry; it is not defined by having no initial human involvement whatsoever. Real malware can combine mechanisms, so classify the behaviour rather than assuming every sample fits only one label.

Improved code quality reduces exploitable weaknesses: validate inputs, check bounds, avoid unsafe memory handling, handle errors appropriately, review code and test security-relevant boundaries. These methods target failures such as an unchecked input corrupting memory or a service accepting an unauthorised operation. Correcting a known vulnerability and applying the patch removes an opportunity for exploitation; code quality alone cannot stop a user deliberately granting an impostor access.

Monitoring includes reviewing logs, detecting unusual connections or processes, and scanning for known or suspicious behaviour. It can reveal an infection or attempted exploitation so defenders can isolate an affected host and investigate. An alert is evidence to assess, not proof that all other machines are clean.

Protection includes maintained anti-malware tools, prompt patching, least-privilege accounts, controlled downloads, staff awareness, and firewall rules limiting exposed services. Backups and tested restoration reduce the damage from lost or corrupted data, but do not themselves prevent infection. No single product guarantees protection from every new threat.

For example, a worm exploiting an exposed service is addressed by fixing/patching the service and restricting unnecessary access, with monitoring to identify infected hosts. A trojan disguised as a tool calls for trusted distribution, careful permission decisions and endpoint detection as well as secure software. Match each defence to what it actually controls.