Reflexive ACL's for Linux?

OlRoy · 11-13-2003, 12:56 AM

http://www.cisco.com/univercd/cc/td/...3/screflex.pdf

Is there anything like this for linux? For the lazy reflexive rules are better than established rules used by IPTables because established lets in traffic just based on whether it has a ACK or RST flag set. With the reflexive rules once a session is initiated it automagically creates a more specific temporary rule that not only goes by the ACK or RST flag but also by the source and destionation IP and port numbers for that session. Another benefit to this is that unlike established rules with IPTables, reflexive rules can be created for other IP protocols like UDP and ICMP, instead of just TCP. Does linux have anyting like this?

I read that huge IPTables Tutorial which i assumed covered everything a while ago and have just recently found out that you can match strings which wasn't mentioned in the tutorial so hopefully i'm not missing out on anything else...

/bin/bash · 11-14-2003, 04:01 AM

Configuring IP Session Filtering
(Reflexive Access Lists)

Quote:

Reflexive access lists, however, provide a truer form of session filtering, which is much harder to spoof because more filter criteria must be matched before a packet is permitted through. (For example, source and destination addresses and port numbers are checked, not just ACK and RST bits.) Also, session filtering uses temporary filters which are removed when a session is over. This limits the hacker’s attack opportunity to a smaller time window.

Moreover, the previous method of using the established keyword was available only for the TCP upper-layer protocol. So, for the other upper-layer protocols (such as UDP, ICMP, and so forth), you would have to either permit all incoming traffic or define all possible permissible source/destination host/port address pairs for each protocol. (Besides being an unmanageable task, this could exhaust NVRAM space.)

From Iptables Tutorial 1.1.19

Quote:

As you can see, it is really quite simple, seen from the user's point of view. However, looking at the whole construction from the kernel's point of view, it's a little more difficult. Let's look at an example. Consider exactly how the connection states change in the /proc/net/ip_conntrack table. The first state is reported upon receipt of the first SYN packet in a connection.

Code:

tcp      6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
     dport=1031 use=1

As you can see from the above entry, we have a precise state in which a SYN packet has been sent, (the SYN_SENT flag is set), and to which as yet no reply has been sent (witness the [UNREPLIED] flag). The next internal state will be reached when we see another packet in the other direction.

Code:

tcp      6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
     dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
     use=1

Now we have received a corresponding SYN/ACK in return. As soon as this packet has been received, the state changes once again, this time to SYN_RECV. SYN_RECV tells us that the original SYN was delivered correctly and that the SYN/ACK return packet also got through the firewall properly. Moreover, this connection tracking entry has now seen traffic in both directions and is hence considered as having been replied to. This is not explicit, but rather assumed, as was the [UNREPLIED] flag above. The final step will be reached once we have seen the final ACK in the 3-way handshake.

Code:

tcp      6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
     sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
     sport=23 dport=1031 use=1

In the last example, we have gotten the final ACK in the 3-way handshake and the connection has entered the ESTABLISHED state, as far as the internal mechanisms of iptables are aware. After a few more packets, the connection will also become [ASSURED], as shown in the introduction section of this chapter.

As you can see the connection is actually tracked by source ip/port destination ip/port. So it would seem to be the same type of tracking.

OlRoy · 11-15-2003, 03:18 PM

Thanks, I should of known linux wouldn't let me down. I've got /sbin/modprobe ip_conntrack running now... Almost hacker proof