Vasileios-Mavroeidis
commented
3 years ago As we can see in terms of actuator function, the stateful capability is something that is not really configurable. On AWS is a matter of choice if we use the relevant ACLs for stateless or stateful capability. The configuration is similar. I think that we need to re-discuss our strategy to extend the packet filtering specs. I think that the way to go is with a general packet filtering spec that we will include all common properties from stateless and stateful.
Then let's discuss how should we address the particular properties of cloud implementations.
Something to be discussed: AWS considers direction a stateful capability (it doesnt affect us) and the options are any and forward. Forward is of any direction based on the logic that we created the rule. Any means that the source and dst addresses are interchangeable.
Edit: Things to remember: AWS firewall supports TCP flags, like CISCO ACL.
Packet filtering, whether performed using a state table lookup or not, has the goal of either allowing or rejecting packets. I contend that there is significant similarity, with the primary differences being rule simplicity, allowing return traffic, supporting complex protocols (SIP,FTP,RPC) and performance.
Example 1: Deny 1.1.1.1 stateless: action:deny, ipv4_net:1.1.1.1 stateless outcome: any packet where the src or dest ip field contains 1.1.1.1 will be discarded stateful: action:deny, ipv4_net:1.1.1.1 stateful outcome: any packet where the src or dest ip field contains 1.1.1.1 will be discarded unless the packet matches an allow setting and has an existing entry in the state table
Example 2: Allow 2.2.2.2 ingress stateless: action:allow, ipv4_net:2.2.2.2, arg:slpf:direction:ingress stateless outcome: any packet where the src or dest ip field contains 2.2.2.2 will be forwarded when the packet is received on the particular interface from another network. This is probably implemented as two rules, but one will typically not be used unless you are say a backbone provider. stateful: action:allow, ipv4_net:2.2.2.2,arg:slpf:direction:ingress stateful outcome: any packet where the src or dest ip field contains 2.2.2.2 will be forwarded when the packet is received on the particular interface from another network. This is probably implemented as two rules, but one will typically not be used and wont make much sense (say ingressing as dest ip 2.2.2.2 when you dont advertise that network), again, unless there is a entry already in a state table.
Example 3: Allow dst port 33 for TCP stateless: action:allow, ipv4_connection:dstport:33, proto:tcp stateless outcome: any TCP packet where the dest port field equals 33 will be forwarded. This is probably implemented as two rules so to allow inbound and outbound packets. stateful: action:allow, ipv4_connection:dst:33, proto:tcp stateful outcome: any TCP packet where the dest port field equals 33 will be forwarded. This is probably implemented as two rules (but could be just one) so to allow inbound and outbound packets, again, unless there is a entry already in a state table.
Example 4: Deny src=4.4.4.4,dst=5.5.5.5,dport=443,dir:egress stateless: action:deny, ipv4_connection:src:4.4.4.4,dst:5.5.5.5,dstport:443 stateless outcome: any TCP/UDP packet where the dest port field equals 433 will be discarded when src=4.4.4.4 and dst=5.5.5.5. This is probably implemented as two rules (tcp and udp) on an interface stateful: action:action:deny, ipv4_connection:src:4.4.4.4,dst:5.5.5.5,dstport:443 stateless outcome: any TCP/UDP packet where the dest port field equals 433 will be discarded when src=4.4.4.4 and dst=5.5.5.5 unless there is an entry in an existing state table. This is probably implemented as one rule.
How do these differ in actual products?
Mechanism in iptables to use state: connection tracking. Basically just a flag for a rule e.g. established Mechanism in AWS to use state: very different. Stateless uses NACLs which apply at the network boundary, whereas stateful uses security groups which apply to the host interface. Mechanism in Palo Alto Networks: very unusual and rare. This is a stateful platform. You can disable statefulness, but it is not granular, it is zone or global and rarely used except in asymmetric environments. Mechanism in GCP: GCP only supports stateful rules