I can't believe I'm talking to a fish about security.
> -----Original Message-----
> From: HUNGRY PIRANHA [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 1 September 2000 11:28 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: cisco access-lists
>
>
>
> justin,
> first of all, the sequence of events you've been told is horseshit...
While I recognise that it's important to have people that are passionate
about their field, I think you could possibly consider moderating your
approach to conflict of opinion situations.
> first of all DO NOT !! apply access-groups to non-existant or
> incomplete
> interfaces, this is a bad idea.
Why is that, exactly? Access lists can't be applied to a non-existant
interface, for a start, but I assume that you're talking about applying
incomplete ACLs. If an ACL does not exist but an ip access-group statement
exists on the interface, the traffic will pass as if there is no ACL. This
is by design. If you have an ACL applied on an interface, as soon as you
start entering the ACL (say you're replacing an ACL, for example) it will
take effect, line-by-line, with a deny base.
This is often inconvenient for remote configuration, but hardly a security
issue.
My favourite method is to create a _new_ ACL with the modifications, and
change the ip access-group xxx in|out command on the interface - this avoids
the few seconds of having no ACL at all.
> in building your access-list from secure stanpoint...
> block those pesky rfc1918's....first
>
> no access-list 100
>
> access-list 100
>
> **preface lines below with access-list 100
> deny ip 10.0.0.0 0.255.255.255 any log
> deny ip 172.16.0.0 0.15.255.255 any log
> deny ip 192.168.0.0 0.0.255.255 any log
You missed spoofed packets for the real IP range - more of an issue than
spoofed RFC1918 addresses, in my book.
>
> then allow tcp established back in...
>
> permit tcp any 120.120.x.x 0.0.255.255 established
>
> then block a lot of non-essential udp stuff...
>
> deny udp any any eq 2049 log
> deny udp any any eq 31337 log
This is only useful if you want to log this sort of traffic. In most
production environments I'd rather forgo these sort of statements in favour
of faster ACL processing. The deny base will catch all the UDP stuff you
don't want, so blocking things here does nothing for security.
>
> then permit service related udp's
>
> permit udp host x.x.x.x x.x.x.x gt 1023
Uh... I don't like that one. That permits _any_ UDP to high ports anywhere
in my network. Ick.
> permit udp host x.x.x.x x.x.x.x eq 53
Or that one. Not all DNS servers use port 53 for server-to-server queries
(which is a shame). You've also allowed anyone on the Internet to attack the
internal DNS server from any UDP port.
A better way to secure DNS (assuming you're stuck with static ACLs) is to do
things like:
permit udp host [my upstream DNS] eq 53 [my DNS cache]
If you're really paranoid you could refine the concept further, but if
you're really paranoid you wouldn't be using static ACLs.
> permit tcp host x.x.x.x x.x.x.x 0.0.0.255 eq 25 ! smtp
Usually you'll not want to do that. Most people want to be able to get mail
from anywhere, but if you have all your mail coming in from an external
relay (at an ISP for example) I guess that could fly.
>
> then start making most specific permits and denials as needed
> with logging where needed
>
> it an exact science, not guess work...
Maybe a little more exact than you first thought.
Cheers,
--
Ben Nagy
Network Consultant, Volante Solutions
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.]
