Rebex SFTP Server throws System.Net.Sockets.SocketException

0 votes
asked Sep 11 by asgallant (240 points)

My Rebex SFTP server is throwing a lot of instances of System.Net.Sockets.SocketException, in two variants:

  • System.Net.Sockets.SocketException (995): The I/O operation has been aborted because of either a thread exit or an application request
  • System.Net.Sockets.SocketException (10060): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

These seem to correlate with penetration attempts by someone attempting to log in as root or admin (immediately rejected by my auth system), but the error is thrown before I can capture any information about the request, so I can't tell for certain.

What would cause these errors? Is there a way to prevent them?

Applies to: Rebex SFTP

1 Answer

+1 vote
answered Sep 12 by Lukas Pokorny (104,290 points)
selected Sep 12 by asgallant
 
Best answer

Compromised serves that attempts to penetrate more servers by logging in as root or admin (or a number of other account names) have unfortunately been widespread on the Internet for years.

In many cases, these attackers don't handle various unexpected situations gracefully and might abort the connection prematurely, for example. This apparently leads to situations that are reported as errors by Rebex File Server, even though they could be just improperly terminated connections or sessions.

We would like to handle these occurrences in a better way (such as detecting them and logging them at LogLevel.Info only). We already have a case open for this and it we will address in in one of the next releases. Would it be possible to create a server log using FileServer object's LogWriter feature, locate some of these errors (with stack traces and context) and mail us the relevant parts of the log for analysis (to support@rebex.net)? This would ensure we do in fact address these particular issues.

commented Sep 12 by asgallant (240 points)
I'm not sure how helpful our logs of these errors will be. The `ILogWriter` interface methods don't allow us to capture stack trace in the logs. The best we get is what comes across in the full message:

```
Session 285932: Error: System.Net.Sockets.SocketException (10060): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

   at twvx.xbkm(Int32 mt, Int32 mu, Int32 mv, Int32 mw, SocketException mx)
```

And a bit of context:

```
Area: Server,
ObjectId: 1,
ObjectType: Rebex.Net.Servers.FileServer
```
commented Sep 13 by Lukas Pokorny (104,290 points)
These logs seem to be just what we need. The stack trace is there (those "at twvx.xbkm(Int32 mt, Int32 mu, Int32 mv, Int32 mw, SocketException mx)" entries) and will make it possible for us to tell where in our code each of those exceptions occured.
commented Sep 13 by asgallant (240 points)
OK. I looked over a few dozen log entries, and they all point to `twvx.xbkm(Int32 mt, Int32 mu, Int32 mv, Int32 mw, SocketException mx)`, for both SocketException types.
commented Sep 13 by Lukas Pokorny (104,290 points)
Thanks, if all of those entries point to the same location, this will be sufficient. We'll address this in the next release.
commented Sep 13 by asgallant (240 points)
We actually had a new exception show up today, which is probably related:

```
Session 3032: Error: twvz: Broken packet - bad length.

   at twvu.depu(hbjc lr)
   at twvx.xbkq()
   at twvx.xbkm(Int32 mt, Int32 mu, Int32 mv, Int32 mw, SocketException mx)
```
commented Sep 17 by Lukas Pokorny (104,290 points)
Thanks! This indicates that the client sent invalid data, which again might be common with malicious SSH clients because compatibility is at the bottom of their creators' priorities. We'll log these at LogLevel.Info as well.
...