Thanks! It seemed like we were only picking on poor FTP.
On 9/26/2024 3:51 PM, Joel Ewing wrote:
On 9/26/24 11:57, Tom Brennan wrote:
> Any attacker with access to FTP on zOS who
> knows valid zOS userids can quickly attempt logins on all of them
with a
> small number of bad passwords and disable logins to those userids by
> their valid users.
Can't an attacker do the same via almost any connection method, such
as SSH, TN3270, REST API's, or other TCPIP applications that ask for
an id and password?
Most certainly! Those standardized services that use simple text login
interfaces that have been publicly documented and widely understood by
the Linux community for decades (like FTP, SSH) are just the most
dangerous exposures, as they require the least expertise and very simple
tools, and even an amateur attacker with no knowledge of z/OS could be
disruptive.
Anytime you expose a z/OS service requiring a RACF login to the outside
world, clearly there should be some level of front-end protection beyond
just a userid and fixed password to prevent disruptive login attempts by
unauthorized users. I assume there are multiple options available today
to accomplish that, but suspect it still requires a network Remote
Access Server to securely pre validate remote users (via smartcards,
authentication app, validation codes, etc.) before the remote user is
allowed to communicate with z/OS.
JC Ewing
On 9/26/2024 9:00 AM, Joel Ewing wrote:
It used to be, and presumably still is, trivial to script a FTP login
sequence from PC platforms. While RACF max login attempts does by
default prevent this from being a useful means to gain unauthorized
access to any account or data, it does make this an easy route for a
denial-of-service attack. Any attacker with access to FTP on zOS
who knows valid zOS userids can quickly attempt logins on all of them
with a small number of bad passwords and disable logins to those
userids by their valid users. Obviously not good for critical
userids. I don't remember the details, but out of an abundance of
caution, before enabling FTP service on zOS we modified some FTP exit
to fail the FTP login attempt without even checking the password if
the userid was not permitted FTP access. I believe it involved
granting the FTP userid access to RACF profiles with resource names
that contained those userids that were permitted to use FTP service.
Similarly, the ability to submit JES jobs via FTP scripts could be a
problem with denial of service even if no submitted job has the
ability to bypass data security. An out-of-control script
(intentional or accidental) that quickly flooded the JES queues with
jobs could tie up enough JES resources to cause zOS operational
problems, either delaying or preventing the submission of other
jobs. To minimize experimentation and accidents, it seems reasonable
to me to only grant FTP job submission capability to a userid when
there was a actual job-related need (which was very rare at the time).
While FTP may not be an exposure for bypassing RACF security, it does
have potential issues for zOS availability that should be considered.
JC Ewing
On 9/26/24 08:21, Tom Longfellow wrote:
Let's all take pity on FTP. Over the years I have been pelted
with questions and criticisms for FTP.
There is the crowd that seems to be unable to understand the simple
process. Transfer a file from A to B. To this day, I cannot figure
these people out. There was a time when I wished I could be paid by
the question of "how does this work"
These same people will blindly accept that Windows is reading an
writing files from around the planet on a daily basis (email
anyone, your favorite cloud or shared drive)
The Fear Uncertanty and Doubt (FUD) from auditors and network people
is astounding. Some think that connecting via FTP give the user
"superpowers" to bypass security, read and write whatever they want
and crash your system. This myth got started from some distant
point in the past and will not die. Others are strong followers of
the School of "If you CAN encrypt, you MUST encrypt" and FTP is not
encrypted by default.
Those of us in the know are aware that FTP goes through the same
authentication as the classic LOGIN function. RACF can fully
secure who and what you touch. And show me one system crashed by
FTP. Encryption can be added to the process.
But, criticizing that thing you don't understand (FTP or even z/OS)
is easier than actually analyzing the prolem you just dreamed up.
The only 'exploits' I have heard of are related to the ability to
submit jobs to JES and network sniffers that capture the
authentication detail for the user. The JES case is a moot point
since you must authenticate to submit this evil job you have
plotted. RACF can be used to control everything, including the
ability to submit at all.
A properly configured system can deny all of these apocyphal falls
from the book of FUD. Security begins at home. If you are not
locking your door, then you are open to attack.
In pactice this is not done because it 'rocks the boat' and
introducing a more secured FTP will upset that program written in
1976. Each site must decide just how important overall security is
to them.
[minor apologies for the pre-Friday rant]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
