Scarica PND Parziali (IPsec) e più Appunti in PDF di Sicurezza delle reti solo su Docsity!
26 - Filter Rules
Created Checkbox Select Theory Status Done
Conceptual Takeaway
Filter rules are the mechanism through which a firewall transforms abstract security goals into concrete packet-level decisions. They are essential, but also delicate: a rule that looks correct in isolation may become dangerous once placed in a larger topology or combined with other rules. Filter rules exist in both stateless and stateful firewalls, but in stateless firewalls they are based only on packet headers, while in stateful firewalls they can also rely on connection state, allowing them to distinguish between new and established connections and making them more expressive and reliable. A network firewall enforces security through a set of filtering rules, each defining: a condition on packet fields an action (typically allow or deny) In the simplest case, the action is either allow or block, but the real complexity lies in deciding which traffic should match which rule. A rule typically matches on: source and destination IP address source and destination port protocol traffic direction (ingress/egress) optionally TCP flags Packets are evaluated sequentially, and: the first matching rule determines the action.
From Security Policy to Firewall Rules
The starting point is never the rule itself. The starting point is the security policy. A policy expresses what the organization wants to permit or forbid. Statements are still too abstract for a firewall. So they must be translated into technical conditions based on packet headers. This is the key passage from policy to filter rule. “Only the mail gateway should receive incoming SMTP traffic” can become something like: allow TCP packets coming from the Internet and destined to the mail gateway on destination port 25 block all other unmatched traffic This translation step is where many mistakes happen, because a policy that sounds clear in natural language can be surprisingly ambiguous when converted into packet-level conditions.
What a Filtering Rule Really Looks At
April 17, 2026 4 16 PM 26 - Filter Rules 1
A packet filter only sees fields in the packet. So when we write firewall rules, we are not directly allowing “email”; we are allowing packets with characteristics that we interpret as email-related, such as: protocol = TCP destination port = 25 specific destination host = mail gateway This is already a limitation, because the firewall is making decisions based on a small set of visible parameters, not on the full meaning of the communication.
The Importance of Direction
One of the central ideas in firewall rules is that traffic must be evaluated not only by where it is going, but also by where it is coming from and through which interface it enters or leaves. This is why we distinguish between: egress filtering: rules applied to packets leaving a network or interface ingress filtering: rules applied to packets entering a network or interface If we only look at the destination, we risk allowing malicious traffic that forges its source. This is especially relevant for address spoofing. For example, suppose that a firewall allows packets to reach internal net 2 if they appear to come from internal net 3. If the firewall only checks destination and does not properly verify the incoming interface and source consistency, an attacker from outside may forge a source address belonging to net 3 and bypass the intended policy. So in a realistic topology, firewall rules must express both: the expected destination of packets the legitimate source and arrival direction of those packets This is why complex network firewalls often define different rule sets for different interfaces.
Interface-Based Filtering
In a firewall that connects multiple networks, rules are often written per interface. For instance, suppose we have: a DMZ containing a mail gateway two internal networks an Internet-facing interface Then the firewall may enforce different logic on each side. On the Internet-facing interface, the firewall should usually reject packets claiming to come from internal networks, because such packets should never arrive from outside. This is a classic ingress filtering measure against spoofing. On the DMZ interface, the firewall may allow the mail gateway to contact only specific external partner mail servers and to send replies to internal networks only when those replies are part of established or expected communication. On the internal network interfaces, rules may allow hosts to initiate outgoing connections, while blocking unsolicited incoming traffic. This shows an important point: firewall rule design is not just about services, but also about network topology. The same service may require different rules depending on which interface the traffic crosses.
Rule Ordering and Default Behavior
Packet filters normally evaluate rules from top to bottom. The first matching rule is applied, and processing stops there. This has two major consequences. 26 - Filter Rules 2
This creates a dangerous situation: rules are syntactically correct, but semantically weak
Using TCP Flags to Infer Connection Direction
Because a stateless firewall does not maintain connection state, administrators often try to infer direction using TCP flags, especially the SYN and ACK flags. The basic idea is this: a new TCP connection usually starts with a packet that has SYN set replies to an already initiated connection usually carry ACK So, instead of saying only: allow inbound traffic to high ports we can say something more precise, such as: allow outbound packets from internal hosts to destination port 25 allow inbound packets to internal high ports only if the ACK flag is present This improves the situation, because unsolicited incoming packets without ACK are blocked, while expected replies are allowed. However, this is still only an approximation. The firewall is not tracking the full session; it is just guessing packet role from visible flags. That is better than pure port-based filtering, but still much weaker than true stateful inspection.
🧩 Complexity in Real Topologies
As networks grow more complex (multiple internal networks, DMZ, Internet), rules must encode: who can initiate communication toward which destination on which interface with which expected return behavior At this point, rule sets become tightly coupled with the network architecture. 👉 Firewall design becomes not just filtering, but topology-aware policy enforcement.
⚠ Structural Limitations of Packet Filters
Stateless firewalls suffer from several fundamental limitations: they rely on a small set of parameters → risk of over/under-permissive rules they do not inspect application data they provide limited visibility and context they lack authentication of the sender they can be bypassed through packet manipulation or evasion techniques 26 - Filter Rules 4
27 - Other Firewalls
Created Checkbox Select Theory Status Done
🧩 Application-Level Filtering (Proxy Firewalls)
Application-level firewalls, often referred to as proxy firewalls, operate at the application layer and are able to inspect the actual content of network communications. Instead of simply forwarding packets, they act as intermediaries between the client and the server, effectively terminating the connection and establishing a new one on behalf of the client. This allows them to analyze protocol-specific details (e.g., HTTP, FTP, SMTP , making them significantly more powerful in detecting malicious behavior compared to lower-layer firewalls. Because of this deep inspection capability, they can log, audit, and control user activity with a high level of granularity. However, this approach comes with important trade-offs. Each application typically requires a dedicated proxy mechanism, which increases complexity and introduces significant performance overhead. Despite this, proxy firewalls can support user authentication, requiring clients to log in before accessing external services.
🔄 Circuit-Level Gateways and TCP Relays
Circuit-level gateways operate at a lower level compared to application proxies, typically at the session layer Layer 5 . Instead of inspecting application data, they focus on managing and relaying connections between clients and servers. A common implementation is the SOCKS protocol, which acts as a generic proxy capable of supporting multiple protocols, including both TCP and UDP. In this model, the client establishes a connection with the proxy, which then forwards the traffic to the destination in a protocol-independent way. Unlike application-level firewalls, circuit-level gateways do not inspect the content of traffic, making them more lightweight but also less secure in terms of content filtering. They can still enforce basic access control policies (e.g., based on IP addresses and ports) and support user authentication. A simpler form of this concept is the TCP relay, which forwards TCP connections without analyzing their payload. While efficient, this approach provides limited security benefits compared to more advanced firewall types.
🖥 Host-Based Firewalls
Host-based firewalls are deployed directly on individual machines rather than at the network boundary. Their primary goal is to protect a single host by controlling which services and ports are accessible. They allow fine-grained control over incoming and outgoing traffic, enabling only the services that are strictly necessary. For example, a personal device may block remote SSH access entirely if it is not required. These firewalls play an important role in defense in depth. Even if a network-level firewall is bypassed or a system is compromised, host-based firewalls can limit the attackerʼs ability to move laterally or access sensitive services.
🚀 Next-Generation Firewalls (NGFW)
Next-generation firewalls extend traditional firewall functionality by integrating multiple security features into a single system. In addition to basic traffic filtering, they often include capabilities such as Intrusion Detection Systems IDS , Deep Packet Inspection DPI , VPN support, and traffic shaping. This allows them to detect and respond to more sophisticated threats that cannot be identified through simple rule-based filtering. As a result, NGFWs represent a more comprehensive approach to network security, combining multiple layers of protection within a unified platform. April 7, 2026 10 39 AM 27 - Other Firewalls 1
In this scenario, the firewall sits between the LAN (private network) and the WAN Internet) and performs both packet forwarding and address translation. Traffic originating from the LAN is translated and then forwarded to the WAN, while incoming traffic from the WAN is filtered and controlled before being allowed inside. As a result, internal hosts are not directly exposed to the outside world, since their private addresses are never visible externally.
🔄 Source NAT (SNAT)
Source NAT (SNAT) is the most common form of NAT and is applied to outgoing traffic. 28 - NAT 2
When a device inside the LAN sends a packet to the Internet, the NAT device replaces the source IP address of that packet with its own public IP address. This process is commonly referred to as masquerading, because the internal host is effectively “hidden” behind the NAT device. From the perspective of the external server, the request appears to originate directly from the firewall/router, not from the internal host. When the reply comes back, the NAT device must determine which internal host initiated the connection. To do this, it relies on a NAT table, which keeps track of all active translations by associating internal and external identifiers (such as IP addresses and ports). This table stores associations between: internal IP + port external IP + port 👉 Without this mapping mechanism, the router would not know where to forward incoming responses. 📊 NAT Table and Connection Tracking The NAT device maintains a state table that records active connections and their corresponding translations. This table allows the device to: map incoming responses to the correct internal host handle multiple simultaneous connections using the same public IP correctly support transport-layer protocols such as TCP and UDP Because NAT relies on tracking the state of ongoing communications, its behavior is closely related to that of stateful firewalls. In both cases, decisions are not made on single packets in isolation, but on the context of the entire connection.
🔁 Destination NAT (DNAT)
Destination NAT (DNAT) is applied to incoming traffic and is used to modify the destination IP address (and possibly the port) of packets arriving from the Internet. When a client on the Internet sends a packet to the public IP address of a firewall/router, the NAT device replaces the destination IP address of that packet with the IP address of an internal server. From the perspective of the external client, the service appears to be hosted directly on the firewall/router, while in reality it is provided by a host inside the private LAN. 28 - NAT 3
29 - NAT Types
Created Checkbox Select Theory Status Done We are going to see 3 different types of NAT Static, Dynamic and PAT. Basic NAT includes both Static NAT and Dynamic NAT, which implement different one-to-one mapping approaches. NAPT Network Address Port Translation) corresponds to PAT Port Address Translation).
🔹 Static NAT
Static NAT is the simplest form of NAT and provides a one-to-one mapping between a private IP address and a public IP address. Each internal device is permanently associated with a specific public IP. This mapping is manually configured and does not change over time. For example, a host with private address 192.168.0.1 can always be translated to 200.200.200.. This means that: the same internal host always appears externally with the same public IP external devices can reach the internal host (if allowed by firewall rules) 👉 Static NAT is commonly used when an internal device (e.g., a server) must be accessible from the Internet.
🔹 Dynamic NAT
April 16, 2026 3 46 PM 29 - NAT Types 1
Dynamic NAT also provides a one-to-one mapping, but in this case the public IP is not fixed. Instead, the NAT device uses a pool of public IP addresses, and assigns one of them to an internal host dynamically, when needed. So: a private IP is temporarily mapped to a public IP the assignment may change over time the mapping exists only while the connection is active For example, 192.168.0.3 could be translated to 200.200.200.7 , but in another session it might use a different public IP. 👉 Because of this dynamic behavior, it is generally not possible to reach internal hosts directly from outside. However, Dynamic NAT still requires one public IP per active internal host. This makes it more flexible than Static NAT, but still limited due to IPv 4 scarcity. 🔹 PAT (Port Address Translation) — NAT Overload PAT Port Address Translation), also known as NAT Overload, is the most widely used form of NAT. Unlike Static and Dynamic NAT, PAT allows: 29 - NAT Types 2
NAPT is applied only when traffic leaves the private network traffic inside the LAN (e.g., between 10.0.0.x hosts) is not translated
🔹 The NAPT Translation Table
Every time a translation happens, the router stores an entry in a NAPT table. This entry keeps track of: private IP + port public IP + port Example entry: 10.0.0.4:5555 ↔ 131.204.128.6: 👉 This table is essential to correctly route responses back to the original host.
🔹 Incoming Responses
When the response comes back from the Internet: The packet arrives at the router with: destination = 131.204.128.6: The router looks into the NAPT table It finds the matching entry: 131.204.128.6:8888 → 10.0.0.4: It rewrites the packet: destination becomes 10.0.0.4: The packet is forwarded to the correct internal host 👉 This is why NAT is stateful: without the stored mapping, the router wouldnʼt know where to send the packet.
🔹 Incoming Requests (from the Internet)
29 - NAT Types 4
By default, NAPT blocks incoming connections from the Internet. This happens because: there is no existing entry in the NAT table the router does not know which internal host should receive the packet
🔓 How Incoming Connections Are Allowed
To allow external access, special mechanisms are needed: Port Forwarding Static NAT for ports) → manually map a public port to a specific internal host UPnP Universal Plug and Play) → devices automatically request port mappings ALGs Application Layer Gateways) → help specific protocols that struggle with NAT TURN → used in advanced scenarios (e.g., real-time communications) 29 - NAT Types 5
NAT is often perceived as a security mechanism, but this is only partially true. It provides implicit protection because: internal hosts are not directly reachable unsolicited incoming traffic is blocked (especially with NAPT However: 👉 NAT is not a firewall It does not protect against: internal attacks application-layer vulnerabilities malicious traffic within allowed connections 👉 Real security is provided by firewalls, often combined with NAT. ⚠ Limitations of NAT Despite its advantages, NAT introduces several important limitations. The most fundamental issue is that NAT breaks the end-to-end principle of the Internet. Originally, any host could directly communicate with any other host, but NAT inserts a translation layer in between. Because of this, many applications may not work correctly, especially those that: require direct peer-to-peer communication embed IP addresses inside the payload depend on stable address mappings Examples include: peer-to-peer P 2 P) applications VoIP and real-time communication some encrypted protocols (e.g., IPsec, IKE, Kerberos) Another limitation is the dependency on state. NAT devices must maintain a translation table: if the state expires, connections may be interrupted unsolicited incoming traffic is blocked by default There are also technical challenges such as: issues with IP fragmentation (especially in NAPT incompatibility with certain protocols need for NAT traversal techniques (e.g., UPnP, TURN ⚙ Performance and Operational Issues NAT introduces additional processing overhead because: every packet must be inspected and possibly modified translation entries must be stored in memory This can lead to: increased CPU and memory usage performance degradation under heavy traffic Troubleshooting is also more complex, since: 30 - NAT Pro & Cons 2
IP addresses are continuously rewritten end-to-end visibility is reduced
🔓 NAT Limitations Mitigation and NAT Traversal
🔹 Possible Mitigations Since NAT breaks the original end-to-end communication model of the Internet, several techniques have been introduced to mitigate its limitations. A basic approach is to design applications that do not embed IP address information inside the payload. In this way, NAT only needs to modify packet headers, avoiding inconsistencies between header and payload. A more advanced solution is the use of Application Layer Gateways ALGs . These components are integrated into routers or firewalls and are able to understand specific application protocols, such as FTP, SIP, or SMTP. By inspecting traffic at the application layer, ALGs can modify not only IP headers but also the payload when necessary, ensuring compatibility with NAT. Another important mechanism is Interactive Connectivity Establishment ICE , a framework designed to establish communication between hosts located behind NAT devices. ICE relies on two fundamental protocols: STUN Session Traversal Utilities for NAT , which allows a host to discover the public IP address and port assigned by the NAT TURN Traversal Using Relays around NAT , which relays traffic through an intermediate server when direct communication is not possible Despite these solutions, NAT traversal remains challenging in the presence of encrypted traffic, since payload inspection and modification are not feasible. 🔹 NAT Hole Punching Hole punching is a technique used to enable direct communication between two hosts behind NATs, typically in peer-to-peer scenarios. The key idea is to exploit the fact that NAT allows outgoing traffic, but blocks unsolicited incoming traffic. If both hosts initiate communication toward each other, they can create the necessary state entries in their respective NAT tables, effectively “opening a hole” for incoming packets. As a result, once these mappings exist, packets can flow in both directions, even though direct inbound connections would normally be blocked. 🔹 Role of a Third-Party Server In most cases, a third-party server is required to coordinate the communication between two hosts behind NATs. This server acts as a signaling entity, allowing peers to exchange information about their public endpoints IP address and port assigned by their NAT devices). Once both hosts know each otherʼs public endpoints, they can attempt to establish a 30 - NAT Pro & Cons 3
31 - iptables
Created Checkbox Select Theory Status Done
🧱 Iptables Fundamentals
Iptables is the packet filtering framework used in Linux systems to control how network traffic is handled. Instead of applying rules in a flat or unstructured way, iptables organizes them into a hierarchy that gives precise control over packet processing. At the highest level, rules are grouped into tables, each designed for a specific purpose. Inside each table, rules are further organized into chains, which represent different points in the packet processing flow. When a packet enters the system, it is not evaluated against all rules at once. It traverses a specific chain, where rules are checked sequentially. This leads to a fundamental principle: the first matching rule determines the fate of the packet This means that rule ordering is critical. A general rule placed before a more specific one may override it completely, making the latter ineffective. If a packet reaches the end of a chain without matching any rule, its fate is determined by the default policy of that chain, which is typically either ACCEPT or DROP.
🔄 The Filter Table and Packet Flow
The most commonly used table in iptables is the filter table, which is responsible for standard packet filtering decisions. This table is built around three fundamental chains, each corresponding to a different role that the system can play in the network. INPUT → packets destined for the local machine OUTPUT → packets generated by the system FORWARD → packets passing through the system (routing) April 29, 2026 4 29 PM 31 - iptables 1
From a logical perspective, every packet is first classified based on its destination. If it is meant for the local host, it goes through INPUT. If it is generated locally, it goes through OUTPUT. Otherwise, if the system is forwarding traffic, it is processed by the FORWARD chain. Again, in all cases, the same rule applies: rules are evaluated sequentially, and the first match decides the outcome.
⚙ How Rules Are Built (Syntax Logic)
An iptables rule is essentially a combination of conditions and an action. The syntax may look complex at first, but it follows a very clear logic: each part of the command progressively refines how packets are matched and what should happen to them. A rule always specifies where it should be applied, what kind of traffic it should match, and what action should be taken when a match occurs. The syntax follows this structure: iptables -t -A [match conditions] -j A rule defines three main aspects: where it is applied (table and chain) what traffic it matches what happens when a match occurs The first part of the command defines the context of the rule. This includes the table (if explicitly specified) and, most importantly, the chain where the rule is inserted. In practice, this determines at which point in the packet processing pipeline the rule will be evaluated. The central part of the rule is the set of matching conditions. These conditions describe the characteristics that a packet must have in order to trigger the rule. These conditions are combined logically: a packet must satisfy all of them to be considered a match. This means that each additional condition makes the rule more specific. The final part of the rule defines the target, which represents the action applied to matching packets. This is what ultimately determines the fate of the packet, such as allowing it, dropping it, or passing it to another chain.
🧠 Extending Rules with Modules
Basic matching can be extended through modules using the -m option: iptables provides modules, which extend the matching capabilities. These modules allow rules to go beyond simple packet inspection and introduce more advanced logic. The most important case is connection tracking, which allows iptables to behave like a stateful firewall. Instead of analyzing packets in isolation, it can understand their role within a communication. Through connection tracking, the firewall can understand whether a packet belongs to a new connection, an already established one, or a related communication. This adds context to filtering decisions, making them much more accurate compared to purely stateless approaches. Common states include: NEW (^) → starting a connection ESTABLISHED → part of an ongoing connection RELATED → related to an existing connection INVALID →^ not^ recognized
🔄 How a Packet Is Processed
When a packet enters the system, it is directed to a specific chain depending on its role INPUT, OUTPUT, or FORWARD . Inside the chain, rules are evaluated sequentially, one after another. 31 - iptables 2
