> Nice script, BUT...
>
> Due to the feature and/or bug referred to recently on this list, this is
> an incredibly dangerous script to run without adequate filtering at all
> your border routers, terminal servers and shell/colocate machines to
> prevent telnet from unauthorized sources.
Agreed.
> Specifically, your script does not properly turn off debugging when it is
> done before closing out the telnet sessions.
Well, really the program isn't supposed to ever exit (for(;;) {}), but I
admit it does set a alarm to kill itself if it doesn't receive some input
within 60 seconds. The main reason for this alarm is because I have
another program that maintains a connection to each PM3 to periodically
issue commands, which needs to "reset console" to avoid getting debug
output intertwined with command output. Unfortunately doing a "reset
console" takes output away from this program.
I think it's unfair to say the script "does not properly turn off
debugging". The situation that causes the program to exit is an attempt
to work around what I consider a flaw in the way PortMasters do debugging.
Specifically in that there is only one current console, one set of debug
flags, lacklustre syslog & snmp support, etc.
For example, Megazone recommended just reconnecting and turning off debug.
If you take a look at it from a security perspective, that is not an
acceptable solution. An attacker might cause your host to become
unreachable, in hopes that the telnet session will time out, and the
attacker could obtain the the virtual terminal spewing output.
Under those circumstances, reconnecting is not a viable option.
Curtisr to say the script "does not properly turn off
debugging". The situation that causes the program to exit is an attempt
to work around what I consider a flaw in the way PortMasters do debugging.
Specifically in that there is only one current console, one set of debug
flags, lacklustre syslog & snmp support, etc.
For example, Megazone recommended just reconnecting and turning off debug.
If you take a look at it from a security perspective, that is not an
acceptable solution. An attacker might cause your host to become
unreachable, in hopes that the telnet session will time out, and the
attacker could obtain the the virtual terminal spewing output.
Under those circumstances, reconnecting is not a viable option.
Curtis
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>