> -----Original Message-----
> From: John Adams [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, 12 March 2000 9:15 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Cisco Access Lists (Was: RE: Content Analysis)
>
>
> On Sat, 11 Mar 2000 [EMAIL PROTECTED] wrote:
>
> > On 03/09/2000 at 14:38:05 CST, "Eric Johnson" <[EMAIL PROTECTED]> wrote:
> > > On 9 Mar 00, at 15:24, John Adams wrote:
> > > > deny ip 192.168.0.0 0.0.255.255 any log
> > > > permit tcp any any lt 1024 established
> > >
> > > Wouldn't locating the permit any established at the start
> of the list
> > > be far more efficient?
> >
> > It might be slightly more efficient, but it would also have
> undesirable
> > side effects. Remember that IOS access lists are processed
> until the first
> > match is found. With the example shown, it would allow any
> tcp packet from
> > the rfc1918 address range that has the ACK or RST bit (the
> meaning of
> > "established") to a port less than 1024. Clearly that is
> not what is
> > wanted.
>
> I doubt it would be more efficient; I want the list to be
> processed in the
> order displayed. There are alot of ports above 1024 that we never want
> passed, so that's the intended result.
>
> -john
It _is_ more efficient to pass all the things you know you're going to pass
first - cuts down on processing time / cycles for permitted packets. As Tony
pointed out the list is short circuited as soon as there is a match. Yes,
you need to be careful with the ordering, but I doubt that Eric meant to
move the rule to the very first entry in the list...
Now for some other comments.
Here's John's original ACL:
ip access-list extended s0-in
! block IP spoofing
[snip some spoofed / dodgy IP ranges]
deny ip 224.0.0.0 15.255.255.255 any log
> This is spoofing?? ;)
[and snip some more]
! block xwindows
[snip some high port blocks]
deny udp any any eq tftp log [1]
[more stuff snipped]
deny udp any any eq tftp [2]
> This will never get matched - it's already matched by [1].
permit tcp any any eq www
permit tcp any any eq 22
permit tcp any any eq ftp
permit tcp any any eq ftp-data
> You support these services on every IP address in your range??
> Also, I think you'd be better off having something like either:
> permit tcp any <my ip range> <my wildcard> eq www OR
> permit tcp any host <my host that supports this service> eq www
> This blocks traffic that's not destined for your IP block.
deny udp any any eq 4045 log
deny udp any any eq syslog
permit udp any any
> Any UDP? What, you allow ICQ or something??
> I'd rather see a DNS specific entry here. If you can't then look
> at the reflexive ACLs (check www.cisco.com)
permit tcp any any gt 1023
> So, effectively you have a permit base for high ports. Not for me, > I'm
afraid.
deny ip 192.168.0.0 0.0.255.255 any log
> Shouldn't this be at the top in your "style" ?
permit tcp any any lt 1024 established
Okay. It looks like you want to support WWW (any ANY machine??) SSH and FTP.
Oh, and DNS, obviously.
I'd write it like this for an imaginary IP block 13.13.13.0/24:
ip access-list extended example
permit tcp any 13.13.13.0 0.0.0.255 established
permit tcp any host 13.13.13.5 eq www !my www server
permit tcp any eq ftp-data 13.13.13.0 0.0.0.255 gt 1023
! This makes non PASV FTP work
permit tcp any 13.13.13.0 0.0.0.255 eq 22
permit tcp any host 13.13.13.6 eq ftp !my ftp server
permit udp host <TRUSTED DNS SERVER1 etc> eq domain host 13.13.13.2
! 13.13.13.2 is my imaginary hardened internal DNS box
! There would be more than one entry here depending on how many
! DNS servers your internal box uses. Some folk only allow root
! servers here (Hi Paul!)
deny ip any any
Differences:
I didn't strip spoofed traffic, because I don't really care. My hosts are
(theoretically) hardened enough against attacks from valid IP ranges so
spoofed packets are hardly going to hurt them. Yes, this is slightly tongue
in cheek. If you want the extra overhead of the eight rules then go ahead -
can't hurt.
I allowed ANY established traffic to high ports. This is a potential hole.
So, if a single forged packet can cause lots of damage to a machine running
a high port service then I would either use reflexive ACLs or NAT - both
have the effect of only opening holes for traffic when a packet actually
leaves the network.
I'd argue that this is _still_ more secure than having a permit base for any
tcp gt 1023 however.
I'm a lot harsher on UDP than John. I'll pick some DNS servers and stick to
them. If anyone wants to run ICQ based apps I'll switch to reflexive ACLs or
tell them "No".
It's about 30 lines shorter. ;)
Cheers,
--
Ben Nagy
Network Consultant, CPM&S Group of Companies
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
