×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Actually regular telnet is explicitly not allowed per PCI security guidelines, the only acceptable forms of Telnet are Telnet over SSL or SSH. See PCI-DSS V2.0 specification 2.2.2.
So if anyone is taking credit cards on an IBM i you may want to read up on that guideline. And it's good practice to not use Telnet anyways and go with a more secure alternative.
-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Thursday, May 17, 2012 1:50 PM
To: Midrange Systems Technical Discussion
Subject: Re: RMTCMD's security?
My point exactly. Everyone is concerned about people's access to RMTCMD or RUNRMTCMD when they really should be securing the end point.
What if your auditor screamed bloody murder because you allowed telnet to or from your server? Would one simply bleat and then turn off the telnet server (ENDTCPSVR *TELNET) and secure the telnet command?
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 05/17/2012 02:12 PM
Subject: Re: RMTCMD's security?
Sent by: midrange-l-bounces@xxxxxxxxxxxx
You should always secure the "to" machine. Securing the "from" machine
isn't even worthy of being called "security".
On 5/17/2012 11:27 AM, rob@xxxxxxxxx wrote:
Should you be securing the "from" machine (ie the system they initiate
the
remote command from), or should you be securing the "to" machine?
midrange.com
