alt.certification.cisco - Access-lists weird output

Author

Access-lists weird output

Naamloos

2003-12-26, 6:24 pm

Hi all,

I have another issue with the access-lists on my router.
When I issue a sh ip access-lists I get the following output:

nixon#sh ip access-lists
Standard IP access list 23
10 permit 10.10.10.0, wildcard bits 0.0.0.255 (4 matches)
Extended IP access list 102
10 permit ip 10.10.10.0 0.0.0.255 any (3765 matches)
Extended IP access list 111
permit tcp host 193.191.136.195 eq 143 host 213.118.79.152 eq 1381 (14
matches)
permit tcp host 195.130.132.70 eq nntp host 213.118.79.152 eq 1385 (10
matches)
10 permit udp any eq bootps any eq bootpc (26 matches)
20 permit udp any eq bootps any eq bootps
30 permit esp any any
40 permit udp any any eq isakmp
50 permit udp any any eq 10000
60 deny icmp any any (302 matches)
70 deny tcp any any (76 matches)
80 deny udp any any (30 matches)
90 deny ip any any
nixon#

First two entrys in acl 111 seem normal, one with the IMAP server from
college and the other one with the nntp server of my provider.

However, when I issue a sh access-lists 111.

Extended IP access list 111
permit tcp host 216.239.59.99 eq www host 213.118.79.152 eq 1376 (4
matches)
permit tcp host 193.191.136.195 eq 143 host 213.118.79.152 eq 1381 (14
matches)
permit tcp host 195.130.132.70 eq nntp host 213.118.79.152 eq 1385 (10
matches)
10 permit udp any eq bootps any eq bootpc (26 matches)
20 permit udp any eq bootps any eq bootps
30 permit esp any any
40 permit udp any any eq isakmp
50 permit udp any any eq 10000
60 deny icmp any any (302 matches)
70 deny tcp any any (76 matches)
80 deny udp any any (30 matches)
90 deny ip any any

What's that first line about??

Is that statefull information from a host trying to access http (the CRWS)
from the outside interface?
Why does it only show up in the second command?
Didn't I deny this using the access lists (it is applied on outside eth
interface going in).

Thank you.

forbesl

2003-12-26, 7:21 pm

Yes, that is a stateful TCP connection showing up on the access-list (matter of fact, it's google.com). Looks like you or someone on your network accessed google.com between the time you issued the first and second "sh ip access-lists" command. I'm assuming you are using NAT/PAT and have CBAC (firewall feature set) configured on your router.

With the exception of your "permits", you ARE denying inbound connections that are initiated from the OUTSIDE; however, this connection appears to be initiated from the INSIDE (you are permitting ALL IP outbound) and by nature of CBAC, the return traffic from the destination will show up on your inbound access-list for the duration of the session. Once the session is terminated (in this case with google.com), the hole is closed.

Naamloos

2003-12-26, 8:24 pm

Ah, now I'm getting the hang of it.
That was me on google searching more info about access lists ;-)

I'm indeed using NAT, and PAT (because I somehow didn't get a DHCP lease
without it, don't know why).
I'm reading up on what CBAC exactly is as we speak
(http://www.sans.org/rr/papers/21/806.pdf).

Is it possible that if a session is still going, someone on the outside
might craft an evil packet that matches the temporary hole in the ruleset?
Would it do any harm?

Thanks for your fast and clear answer.

"forbesl" <forbesl.z2nkg@mail.examnotes.net> wrote in message
news:forbesl.z2nkg@mail.examnotes.net...
>
> Yes, that is a stateful TCP connection showing up on the access-list
> (matter of fact, it's google.com). Looks like you or someone on your
> network accessed google.com between the time you issued the first and
> second "sh ip access-lists" command. I'm assuming you are using
> NAT/PAT and have CBAC (firewall feature set) configured on your
> router.
>
> With the exception of your "permits", you ARE denying inbound
> connections that are initiated from the OUTSIDE; however, this
> connection appears to be initiated from the INSIDE (you are permitting
> ALL IP outbound) and by nature of CBAC, the return traffic from the
> destination will show up on your inbound access-list for the duration
> of the session. Once the session is terminated (in this case with
> google.com), the hole is closed.
>
>
> forbesl
> Sign up for free daily practice questions at: http://www.QoD.US
> ------------------------------------------------------------------------
> Posted via http://www.examnotes.net
> ------------------------------------------------------------------------
> View this thread: http://www.examnotes.net/article1031491.html
>

forbesl

2003-12-27, 8:36 am

I don't believe you have anything to worry about. The hole is opened for that session only. Anyone trying to spoof your session destination IP and send you any screwy stuff from the outside would have to create a new connection to do that....and it would be denied.

Now, that being said, if you INITIATE a connection with a questionable destination IP address, the above statement does not apply. Read up on CBAC; I think you will understand. Stateful packet inspection rules!

Naamloos

2003-12-27, 11:24 am

That's right, it rules big-time!
I've just read that SANS paper about CBAC and now I'm finally starting to
understand it.

Another unrelated question that popped in my mind.
When I put the log keyword in an access-list rule it logs every packet that
matches the rule.

Where is that logging info stored, RAM?
Are there limits applied to the storage space for logs, and what happens
when that storage space is filled up and you don't choose to send SNMP traps
to a logging server?
How do I show the logging info for a specified access-list rule?

"forbesl" <forbesl.z3qgg@mail.examnotes.net> wrote in message
news:forbesl.z3qgg@mail.examnotes.net...
>
> I don't believe you have anything to worry about. The hole is opened for
> that session only. Anyone trying to spoof your session destination IP
> and send you any screwy stuff from the outside would have to create a
> new connection to do that....and it would be denied.
>
> Now, that being said, if you INITIATE a connection with a questionable
> destination IP address, the above statement does not apply. Read up on
> CBAC; I think you will understand. Stateful packet inspection rules!
>
>
> forbesl
> Sign up for free daily practice questions at: http://www.QoD.US
> ------------------------------------------------------------------------
> Posted via http://www.examnotes.net
> ------------------------------------------------------------------------
> View this thread: http://www.examnotes.net/article1031491.html
>

forbesl

2003-12-27, 12:07 pm

The amount of log info stored depends on the size of you logging buffer. You can also configure logging history. Check out this link:

cisco.com/en/US/products/sw/iosswrel/ps1828/ products_command_summary_chapt
er09186a00800eeae4.html (url word-wrapped)

If you want to go a step further, you can download a free syslog daemon for your computer from http://www.kiwisyslog.com. That way you can store your logs to a database and retrieve them whenever you wish. That's what I recommend; the only drawback is that you will have to keep your machine on with the syslog daemon running in the background in order for you to collect the logs.

Sponsored Links