Cisco ACL vs. iptables semantics

I'm not familar with the iptables fields, but I suspect that the answer is NO.

*Every* Cisco ACL, for IOS and PIX, has an implied "deny everything" at the end of it. Therefore your ip access-list extended blockssh is equivilent to "deny ssh, and deny everything else too". If the iptables entries you show do not have those semantics, then they are not equivilent to the ACL.

Note: That's -every- Cisco IOS or PIX ACL, for every purpose I've been able to find. But deny does not -always- mean "drop the traffic": for example, in the context of Policy Based Routing (PBR), a deny in the matching ACL just means that the policy is not in effect for that denied traffic, and that it should be processed through any remaining policies, with a default of going through regular routing-table routing of none of the PBRs matched the packet.

More or less. However, you need only one iptables rule, depending on whether the router itself has the IP 192.168.1.1 or not. I'm going to assume that the router does not have that address, since the second example (blocking outbound SSH to that address) wouldn't make much sense otherwise.

The equivalent rules in iptables would then look like this:

iptables -N blockssh iptables -A blockssh -p tcp -d 192.168.1.1/32 --dport 22 -j DROP

iptables -A FORWARD -i -j blockssh

and

iptables -N blockssh iptables -A blockssh -p tcp -d 192.168.1.1/32 --dport 22 -j DROP

iptables -A FORWARD -o -j blockssh

cu

59cobalt

Walter Roberson wrote:

Of course you are right, I should have phrased my question using better words. Let's try: I know that ACLs "deny" does not always mean "block" or "drop" packets. But here, I was referring to a context of firewalling/packet filtering, so "deny" should really mean "drop" here. Then, you are right about the implicit deny at the end of cisco ACLs, but again I did not make clear what I was trying to understand. Let's use the incoming - first group of rules from my previous example, and assume default policies are already configured the same. My understanding (which of course could be wrong) is that, if a cisco router is running the ACL from my first example and receives a packet that matches (eg, tcp port 22 with destination 192.168.1.1), it drops the packet no matter what. If, instead, the router is a host running iptables, the packet could be assigned either to the INPUT chain (if 192.168.1.1 is an IP assigned to the router) or to the FORWARD chain (if the router's IP address is different). So, if I wanted to write some iptables rule(s) for a "generic" router host whose IP address is not known, and I wanted to guarantee the same behavior, would it be correct (semantically equivalent to the ACL) and enough to write the two rules I wrote, one for the INPUT chain and the other for the FORWARD chain? For the output case, the problem is related, since packets leaving the router could be originating from the router itself or be forwarded by the router. So, the critical info here is the source address of the packet (and yes, as another poster already noted, I should have written my second group of rules differently instead of copying/pasting). Thus, the question: whereas a cisco router running an ACL like

ip access-list extended blah deny tcp 192.168.1.1 0.0.0.0 any eq 22

interface ip access-group blah out

drops a leaving matching packet no matter where it originated, does an iptables firewall (whose IP address is not known) need two rules, one for the FORWARD chain and one for the OUPUT chain?

I hope it's clearer now. Thanks for any help. d

As I just wrote in another reply, I'm not assuming a particular IP address for the router, I just want to guarantee the same behaviour. And you're right, my second example does not make sense if the router has the same IP address. Rather, I should have put the address into the source and used 'any' for the destination. Thanks for noticing that.

Yes, but without knowing the IP address of the router, if you want to make sure that no matching packets enter or leave the router (as cisco ACLs do), you need to add

iptables -A INPUT -i -j blockssh

for the first case and

iptables -A OUTPUT -o -j blockssh

for the second, right?

Thanks d

Yes. However, the default behaviour of iptables is to return a packet to the originating chain if it's not matched in the current chain, which according to Walter's reply differs from the behaviour of Cisco ACLs. To make the rulesets equivalent you'll have to add an explicit DROP at the end of the user-defined chain:

iptables -N blockssh iptables -A blockssh -p tcp -d 192.168.1.1/32 --dport 22 -j DROP iptables -A blockssh -j DROP

iptables -A INPUT -i -j blockssh iptables -A FORWARD -i -j blockssh

and

iptables -N blockssh iptables -A blockssh -p tcp -d 192.168.1.1/32 --dport 22 -j DROP iptables -A blockssh -j DROP

iptables -A INPUT -o -j blockssh iptables -A FORWARD -o -j blockssh

However, I wouldn't feel very comfortable with "default" rulesets for a firewall (except for "deny all" of course). I believe a firewall should always be configured to exactly match the criteria defined in the planning phase, which IMHO forbids such things as "default rulesets".

cu

59cobalt

Yes, I know that. My question was only about *matched* packets, which are unaffected by default policies.

Thanks everybody for your replies. d