Cisco ACL vs. iptables semantics

Am I right in saying that, semantically, the rough iptables equivalent
of this cisco ACL

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

interface
ip access-group blockssh in

is this:

iptables -A INPUT -i -p tcp -d 192.168.1.1 --dport 22 -j DROP
iptables -A FORWARD -i -p tcp -d 192.168.1.1 --dport 22 -j DROP


and, conversely, the equivalent of

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

interface
ip access-group blockssh out

is this:

iptables -A OUTPUT -o -p tcp -d 192.168.1.1 --dport 22 -j DROP
iptables -A FORWARD -o -p tcp -d 192.168.1.1 --dport 22 -j DROP

?

Thanks for any reply.

Re: Cisco ACL vs. iptables semantics

In article <1169142389.971930.123710@s34g2000cwa.googlegroups.com>,
d wrote:
>Am I right in saying that, semantically, the rough iptables equivalent
>of this cisco ACL

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

>interface
> ip access-group blockssh in

>is this:

>iptables -A INPUT -i -p tcp -d 192.168.1.1 --dport 22 -j DROP
>iptables -A FORWARD -i -p tcp -d 192.168.1.1 --dport 22 -j DROP

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.

Re: Cisco ACL vs. iptables semantics

d wrote:
> Am I right in saying that, semantically, the rough iptables equivalent
> of this cisco ACL
>
> ip access-list extended blockssh
> deny tcp any 192.168.1.1 0.0.0.0 eq 22
>
> interface
> ip access-group blockssh in
>
> is this:
>
> iptables -A INPUT -i -p tcp -d 192.168.1.1 --dport 22 -j DROP
> iptables -A FORWARD -i -p tcp -d 192.168.1.1 --dport 22 -j DROP
>
>
> and, conversely, the equivalent of
>
> ip access-list extended blockssh
> deny tcp any 192.168.1.1 0.0.0.0 eq 22
>
> interface
> ip access-group blockssh out
>
> is this:
>
> iptables -A OUTPUT -o -p tcp -d 192.168.1.1 --dport 22 -j DROP
> iptables -A FORWARD -o -p tcp -d 192.168.1.1 --dport 22 -j DROP
>
> ?

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
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Cisco ACL vs. iptables semantics

Walter Roberson wrote:

> 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.

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

Re: Cisco ACL vs. iptables semantics

Ansgar -59cobalt- Wiechers wrote:

> 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.

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.

> 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

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

Re: Cisco ACL vs. iptables semantics

d wrote:
> Ansgar -59cobalt- Wiechers wrote:
>> 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.
>
> 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.
>
>> 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
>
> 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?

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
--
"If a software developer ever believes a rootkit is a necessary part of
their architecture they should go back and re-architect their solution."
--Mark Russinovich

Re: Cisco ACL vs. iptables semantics

Ansgar -59cobalt- Wiechers wrote:

> 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:

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

Thanks everybody for your replies.
d