> 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?
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
