Suggestion...
Make 2 textfiles with the same commands, differing only in respect to the
number of the access control list, e.g:
unixbox> emacs c2501.acl101.txt
[make required changes to ACL]
unixbox> sed 's/access-list 101 /access-list 102/' c2501.acl101.txt >
c2501.acl102.txt
Assuming you already had a working ACL using access-list 101 in the router,
and that you have applied access-group 101 the interface you wish to
protect, assumed here to be serial0:
unixbox>telnet myrouter
[login, enable]
myrouter#conf t
myrouter(config)#[cut/paste access-list 102 from c2501.acl102.txt]
myrouter(config)#in s0
myrouter(config-if)#ip access-group 102 in
myrouter(config-if)#no ip access-group 101
^Z
....
Next time you make your changes, reverse the lists again:
myrouter(config-if)#ip access-group 101 in
myrouter(config-if)#no ip access-group 102
You may stall some traffic for a second or two while there are two ACLs
operating on your interface, but since the interface always has at least one
ACL on it, it seems pretty safe.
Brad
====
(PS .. I scripts to do this stuff, but I expanded the process a little for
clarity.)
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 02, 1999 6:13 PM
Subject: Re: access-list on cisco routers
>
>
> Chris Brenton <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] wrote:
> >> operation, as used by a telnet setup) is made effective as soon as it's
> entered.
> >> This can cause a number of problems; with access-lists the most obvious
issue
> is
> >> that the first command is ususally "no access-list 101" (or similar).
This
> >> means that you've just disabled all filtering for that access-list.
Until
> the
> >> rest of the commands for that list are entered you may be allowing
undesired
> >> traffic.
> >
> >I guess if you are ultra-ultra paranoid, the above is true.
>
> Well, this is the firewalls list.
>
> >You would
> >have maybe a second or two of exposure depending on how many lines are
> >in your access list. Of course this assumes an attacker knows exactly
> >when you will be dropping your guard and can sneak through a nasty
> >session in the allotted time.
>
> I assume (and have the logs to show it) that I'm being scanned and probed
> constantly. No, not every instant, but opening even small windows of
> opportunity is something I prefer not doing.
>
> >> When tftp is used to transfer a configuration file the entire
configuration
> >> update is atomic - all of the changes take effect at once. For
access-lists
> in
> >> particular, this is safer.
> >
> >Actually, that's not correct. TFTP will still wipe out the current
> >access list and then replace it. So if you want to get technical, you
> >still have a period of time where you are exposed. Granted we are
> >talking milliseconds as opposed to a full second or two, but we are
> >talking from an ultra-ultra paranoid perspective. ;)
>
> As to whether a tftp (or rcp) config load is completely atomic, I cannot
say
> (the Cisco web site seems overly silent about this). But there is another
more
> severe exposure with "conf term" that tftp doesn't have. From an old
article of
> mine in comp.dcom.sys.cisco:
>
> *** start of usenet article ***
> In article <[EMAIL PROTECTED]>,
> William "Chops" Westfield <[EMAIL PROTECTED]> wrote:
> >Cisco routers have
> >always been configurable on the fly (sometimes too much so - many is the
> >times a curse has echoed through the halls as someone manages to turn off
> >connectivity via the path they were using to reconfigure the box...)
>
> Yes, and I think at least some of these problems could easily
> be prevented - by an IOS design change.
>
> The problem is that configuration commands take effect immediately.
> Here is an example:
>
> Cisco(config)#no access-list 100
> Cisco(config)#access-list 100 (permit or deny anything)
> ...
> Cisco(config)#access-list 100 (last of many)
>
> When the first command is entered you perhaps no longer have any
> filters on some interface. This is possibly a security exposure
> (maybe only for a short time), but it doesn't prevent you from
> completing the config.
>
> When the second command is entered, you also now have the implicit
> "deny ip any any". This can be a session killer, including the telnet
> or tftp session being used to change the configuration. (Presumably
> other commands in the access-list would enable the communications
> needed for the config session.)
>
> Why oh why doesn't IOS wait until config mode is exited before
> making any changes to the config? At that point, assuming the
> administrator hasn't made an error, you should have a logically
> complete and consistent set of instructions in the config.
>
> *** end of usenet article ***
>
> The answer to that, provided by a couple of folks in the newsgroup, is to
use
> tftp to load configs. I have been hit by the problem mentioned, and I can
> verify that using using a file transfer for loading configs avoids the
problem.
>
> Tony Rall
>
>
> -
> [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.]
