Hey Scott,
You wrote...
"The fact that people on this list (besides Chuck and Rob) seem to be advocating securing the SBMRMTCMD or RUNRMTCMD command is just silly."
So, essentially, yes you did say "securing what can be executed on a system is silly".
Sorry you didn't like my poetry. :)
Now, I have never stated nor implied not securing a server's ingress.
Securing commands such as AREXEC, SBMRMTCMD, RUNRMTCMD, exit points and assorted APIs falls, to my way of thinking, under the concept of restricting egress. Many forget about, are unaware of or maybe ignore restricting egress.
If you secure a server so someone cannot egress one server to ingress another server who cares how the other server is secured. You can't get there anyway because the server you are on won't allow that egress method.
If you secure a server so only trusted individuals can ingress it who cares what other servers they egress to. The other server's ingress restrictions will take over its ingress issues.
Gary Monnier
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, May 17, 2012 3:25 PM
To: Midrange Systems Technical Discussion
Subject: Re: RMTCMD's security?
Hi Gary,
I certainly did not say that securing what can be executed on a system is silly!
Securing SBMRMTCMD won't stop a worm from going here or there -- THAT is my point.
If there were only two systems in the world, and SBMRMTCMD was the only possible conceivable command to submit a command, then your philosophy
might work... but unfortunately, that isn't reality.
An analogy:
Securing the server against running remote commands (which is what I
advocate) is like putting your money in a safe so a robber can't break into your house and steal it.
Securing the server by disabling the client command (which is what you seem to be advocating) is like going to every conceivable criminal's house and breaking their legs so they can't travel to your house to steal your money.
On 5/17/2012 4:59 PM, Monnier, Gary wrote:
Hi Scott,
I'm surprised you feel securing what can be executed on a system as silly. Not doing so, from my knothole onto the world, seems absurd. To me, it is akin to buying a padlock for a locker but not actually locking it!!
If you can't get from system A to System B because the stuff allowing it is unavailable to you who cares how tightly system B is locked down? System A isn't letting you get there anyway.
A worm goes here
A worm goes there
Until it is stopped from going anywhere.
It is stopped when it cannot execute stuff allowing it go somewhere.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
