Tag sftp

As the time to release Syncplify Server! V6 approaches rapidly, we now have the pleasure to begin performing real serious stress-tests on our SFTP engine.

The idea is to “throw everything we’ve got at it”, and try our hardest to make it crash… or at least leak some memory, or misbehave in any way. The underlying concept is: if we can find a way to hack/damage/crash our server, someone else may be able to do the same; so we don’t want that.

Well, enough chit-chat, here’s the raw data, followed by a plain English explanation:

{
    "sessSshSftp":       689841,
    "fileUp":            16552,
    "fileDn":            16433,
    "fileUpFail":        0,
    "fileDnFail":        0,
    "transferUpMb":      "3.156491 TB",
    "transferDnMb":      "3.152610 TB",
    "scriptsRun":        33127,
    "crashOrPanic":      0,
    "successfulAttacks": 0
}

The test ran for 2 hours, with 56 concurrent attackers designed to introduce the highest possible level of fuzziness in their behavior. This is to ensure that neither the server nor our development team knows ahead of time exactly how the attackers will perform their attacks.

Attacks may include any mix of the following:

• protocol violations
• abrupt connection interruptions
• flooding of concurrent rapid-fire connection/disconnection cycles
• authentication tampering or bypass
• permission escalations
• directory traversals
• command injections
• random data packets with wrong size, MAC, or some other wrong syntax/structure/payload

In total, 689,841 client sessions were gracefully handled (~96 sessions per second). The sustained file transfer speed over the course of the 2-hour test was on average 876.26 MB/sec.

Nevertheless, no attack was successful. And, at the end of the test, Syncplify Server! V6’s worker process was still using only ~44.6 MB of RAM.

We feel pretty good about this.