How can admins identify and deal with suspicious authentication attempts?
How can administrators identify suspicious authentication attempts (whether or not the related users are currently locked out)?
Does MOVEit Transfer lock out users that do not exist?
What built-in reports in Transfer can be used for security audits?

Users That Do Not Exist Will Not Be Locked Out

A common question we field goes something like this:
"Last night we watched 953 attempts to sign on as 'root' go into MOVEit Transfer(DMZ).  Why wasn't 'root' locked out?" 

The answer often turns out to be "because there is not have a user named 'root' on your system." 

There are several reasons MOVEit Transfer(DMZ) does not try to "lock out" users that do not exist:

1) Doing so would create longer lists of "locked out" users than "real" users at many MOVEit Transfer(DMZ) installations; several sites are scanned by 'bots which use lists of several hundred common usernames every night. 

2) If a user does not exist, there is no way that a remote client could sign on as that user.  (Even users created automatically through External Authentication require at least one successful signon before the related MOVEit Transfer(DMZ) user exists.)  In this situation, locking out a user that does not exist would be overkill. 

3) When IP lockouts are used in conjunction with user lockouts, the most common 'bot attempts to scan a MOVEit Transfer(DMZ) server for a long list of common username and password combinations is effectively thwarted.  (MOVEit does not lock out users attempted from locked out IP addresses anyway.) 

Reporting Suspicious Authentication Attempts

The current list of locked out users displayed on Admins' home pages should never be considered an authoritative list of suspicious authentication attempts.  There are at least four reasons why  suspicious authentication attempts would not appear on the current list of user lockouts:

1) Your username lockout policy automatically unlocked the suspicious usernames after X minutes
2) Another administrator has manually removed the suspicious usernames
3) The suspicious usernames are being attacked with a "low and slow" scheme that the username lockout code cannot detect
4) The suspicious addresses were attempted through a "dead" interface (or locked-out IP address) through which they would never be able to gain access

Instead, use one of the following built-in MOVEit Transfer(DMZ) Reports to get an authoritative list of suspicious authentication attempts.

1) Security - Suspicious Usernames - Many Attempts - This will show the usernames against which more than X failed attempts were recorded.

2) Security - Suspicious Usernames - Many IPs - This will show the usernames against which more than X failed attempts from more that Y different IP addresses were recorded .

There are options to run reports against the current and historical lists of usernames locked out, but the current list is subject to the four limitations mentioned above and the historical list is still subject to limitations #3 and #4. 

How To Handle Suspicious Usernames

First, get more information about the suspicious usernames.  Specifically, go to "Logs" and filter on any successful entries (including signons) for the suspicious username.  If you find any successful entries outside the normal pattern of behavior, this may be a sign that credentials were successfully guessed, if not used.

To prevent illegal access to a suspicious (but otherwise valid) username, consider:

1) Locking down the suspicious username to a particular IP address(es) or particular interface (such as FTP/S).  

2) Replacing a suspicious username that may be a frequent target (such as "root" or "neo") with something more unique (such as "jack14521").