Most SSH(2) and SFTP servers have some sort of built-in countermeasure against the most common attacks. Although some free solutions may be completely defenseless, the vast majority of corporate-grade SFTP servers are usually capable of protecting themselves against – at least – the following threats:

• DoS (and in some cases DDoS)
• Hammering
• Brute-force
• Password harvesting
• Protocol violations

All of the above protection mechanisms (except the one against “protocol violations”) assume that the attacker is someone from the outside who is trying to either break in and gain control of your machine, or simply tear it down and cause a service interruption.

The last bullet-point, though, is far more interesting, as it takes into account that the “attacker” (which might not even be a real attacker) may a legitimate user of your SSH/SFTP server, with valid authentication parameters, who sends wrongly formatted commands after he/she has successfully logged in.

For example, a legitimate user may try to traverse directory paths to gain access to contents that should be out of his/her reach, or send wrongly formatted/padded command codes or payloads in order to exploit known bugs, or cheat on the upload/download ratio by re-downloading the same file over and over again in order to be allowed to upload a larger one. The possibilities are countless.

That is why, even though most corporate-grade SFTP servers provide built-in countermeasures to some of the above behaviors, usually by means of very long and detailed configuration parameters. But let’s analyze a very common (and simple) case: let’s say that we don’t want a certain user to be able to upload JPG files. This can be done, in most SFTP servers, by configuring a “list of disallowed file types” located somewhere in the settings tree.

Or… it could be done with a simple script. If you are running Syncplify.me Server!, for example, you can easily prevent the upload of JPG files using the following script:

Now, it’s easy to argue that adding the banned extension to a list in the configuration GUI is easier than writing a script. That is true, when the “case” is as simple as this one. But let’s stop for a moment and think: what if our user is clever, and he renames his JPG files to a different extension before uploading them? Say, he/she renames “MyProfilePic.jpg” to “Resume.doc” and then uploads what appears to be a DOC file to the SFTP server.

Clearly such case cannot be addressed by simply banning certain file extensions. But if you are running a scriptable SFTP server, like the Syncplify.me Server! we’re using in our example, then you still can prevent the worst from happening. In fact, we know that a JPG file, regardless of its file name and extension, will always begin withe the same 2-byte sequence (FFD8) and end with the same 2-byte sequence (FFD9). We can therefore write a slightly longer script that effectively identifies the file type by its actual contents, and deletes it if it is a JPG. It also blacklists the client IP for 30 minutes, and forcefully terminates the session (closes the connection). This should discourage the user from trying to upload JPG files again in the future.

This kind of flexibility can be achieved only via scripting. It’s good to have a highly configurable SFTP server, but the possibility to extend its functionality via scripts can make a big difference when it comes to implementing strict custom controls over the users’ behavior.