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.]
