The access should be the same - traffic still gets dropped. However, if
you have NAT statements, inspect statements, etc. on the serial interface,
you have the overhead of processing on these statements before the traffic
is dropped. This may just be a resource issue or could be more of a
problem if there was a security hole with that service in an IOS version.
I prefer to apply the access lists inbound on an interface and drop the
traffic right away.
-Kathleen
_______________________
Kathleen M. Moriarty
Jon Earle
<jearle@dmcs. To: [EMAIL PROTECTED]
dnd.ca> cc: [EMAIL PROTECTED], (bcc:
Kathleen
Moriarty/FactSet)
03/14/00
12:31 PM Subject: RE: Cisco Access Lists (Was: RE:
Content
Analysis)
At 08:30 AM 3/10/00 +0100, you wrote:
> > At 05:30 PM 3/9/00 +0100, you wrote:
> > > > access-list 102 permit tcp 0.0.0.0 255.255.255.255 x.x.x.3
> > > > 0.0.0.0 gt 1023
> > > > access-list 102 permit udp 0.0.0.0 255.255.255.255 x.x.x.3
> > > > 0.0.0.0 gt 1023
> > > > access-list 102 permit tcp 0.0.0.0 255.255.255.255 x.x.x.3
> > > > 0.0.0.0 eq 22
> > > > access-list 102 permit tcp 0.0.0.0 255.255.255.255 x.x.x.3
> > > > 0.0.0.0 eq 25
> > > > access-list 102 permit tcp 0.0.0.0 255.255.255.255 x.x.x.3
> > > > 0.0.0.0 eq 53
> > > > access-list 102 permit udp 0.0.0.0 255.255.255.255 x.x.x.3
> > > > 0.0.0.0 eq 53
> > >
> > > > I initially placed this list on the serial connection,
> > which is the
> > > > incoming isdn. I had defined it as 'ip access-group 102
> > in', which
> > > > promptly cut off all access. I then placed it on the
> > > > ethernet port as 'ip
> > > > access-group 102 out', which appears to work as it should.
> > > >
> > > > Questions:
> > > >
> > > > 1. Why did the first definition not work? I would have
> > > > thought either
> > > > definition would work the same.
> > > >
> > >you denied everything incoming that is standard TCP/IP, so
> > you were able to
> > >send packets; but unable to receive any responses
> > >permit tcp gt 1023
> > >but at the end there is always an implicit deny !!!!
> >
> > But, my first two rules allow responses.
>yes, for the packets which ports are greater (gt) than 1023 (and this
isn't
>regular traffic)
So, shouldn't response packets have been allowed then? According to the
above ruleset, packets from anywhere, destined for the firewall, with ports
set to > 1023, 22, 25, and 53 are allowed. Since outbound access is
unrestricted, why would this have failed to work when placed on the serial0
interface?
I'm utterly failing to see the difference between:
interface serial 0
ip access-group 102 in
and
interface ethernet 0
ip access-group 102 out
when using the above access list.
> >
> > If I think of it this way:
> >
> > e0 serial0
> > FW<----------------[Cisco 2501]<----------------Internet
> > ip access-group 102 out ip access-group 102 in
> >
> > Arrows indicate direction of packet flow. ie: they
> > illustrate packets
> > arriving via the serial interface, and leaving via the
> > ethernet interface
> > (obviously, they flow in both directions, but I'm not concerned with
> > outbound flow). The two definitions should have been
> > identical, wouldn't
> > they? On the serial interface, the list would have matched incoming
> > packets, and on the ethernet interface, the list would match outgoing
> > packets. What is the difference?
> >
>I think that out means leaving, so on e0 out is in the router (the
opposite
>direction of your arrow !)
Wouldn't 'out' refer to packets leaving the router, as you mentioned, and
as I drew? I'm envisioning 'out' in this case, as referring to a packet
which leaves the router via the ethernet interface, and is destined for the
firewall.
>With the established keyword, established connections (after the initial
>TCP/IP hand-shake) are allowed, so reducing the overhead for the router to
>check every packet.
So, if I use the 'established' keyword, I can then get rid of the rules to
allow inbound response packets (> 1023), correct?
Cheers!
Jon
-----------------------------------------------------------------
Jon Earle (613) 612-0946 (Cell)
HUB Computer Consulting Inc. (613) 830-1499 (Office)
http://www.hubcc.ca 1-888-353-7272 (Within Canada/US)
"God does not subtract from one's alloted time on Earth,
those hours spent flying." --Unknown
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
