Feb 14, 2012
Anyone who administers virtually any type of Internet server has seen their server attacked by robots, spammers or other ill-behaved clients. (As a group, I'll just refer to them as "spambots".) It's a fact of life for server administrators, and unfortunately, there's no way to avoid them.
On the front door of your home, you have a lock. The lock doesn't prevent someone from walking up to your house and knocking on the door. What it does is allow you to look out the peephole, see who is there, and decide whether or not to let them in. If you are going to allow some people into your home and deny others, you have no choice but to allow them to walk up to the house so you can see who they are.
An Internet server is no different. Rumpus has numerous security features designed to ensure that the right people have access to the right stuff on your server. But in order to decide who can access what, Rumpus has to let users connect and identify themselves. Rumpus keeps a log of all activity, including the actions of people who "walk up to the door", but that doesn't mean Rumpus has let them into the house.
The short answer is this: Assign good, non-trivial usernames and passwords.
It is stunning how many servers are accessible via a user account named "admin". If you look at your access log following an attack by a spambot, you will very likely see that it tried to log in as "admin" along with many other common usernames. For a password, the spambot will generally try "123456", "password", "admin", "letmein", and other common passwords. The spambot will also replace "l"s with "1"s in common words, "o"s with "0"s, and so on. Even for testing, don't use these trivial username/password combinations. (You might forget to delete the account after the test.)
Good password practices can be readily found on the 'net. Google "how to create good passwords", or similar, for details.
Rumpus does include a feature which watches for a client to make several repeat login attempts within a short period of time. If a client fails to log in after repeatedly being denied, Rumpus will add the client to the "Blocked Clients" list, and thereafter won't even let the client connect. The controls for this feature can be found on the "SpamBots" tab of the Administration Console window.
This feature is handy because it prevents spambots from using network bandwidth and system resources, since any attempt by the client to connect is denied promptly and efficiently before the connection is even fully established. But it doesn't really increase security much, as long as you have assigned well-formed, non-trivial passwords. Using this feature does limit the number of guesses a spambot may attempt, but the number of combinations formed by well-chosen passwords is astronomical. Whether a client is allowed 10 or 10,000 guesses is inconsequential... Either way, the spambot is only going to guess it's way into your server if you assign trivial usernames and passwords.
On some networks, all client activity appears to come from a single IP address. If you run a reverse proxy, for example, all Web activity will appear to Rumpus to come from the proxy server address, since the proxy is connecting to the server on behalf of all clients. Many Apple AirPort extremes (and a few other routers) will make all FTP activity appear to come from one IP address, that of the router. This is due to FTP essentially being proxied inside the router, and is something I've reported to Apple, repeatedly.
In thses cases, IP based security simply won't work. Since all client activity appears to come from one IP address, it's not possible to differentiate user access that way. If you enable "Automatic Hack Recognition" in Rumpus, as soon as one spambot accesses the server, Rumpus will add the apparent IP address to the Blocked Clients list, effectively blocking everyone from accessing the server.
In this case, remove the proxy or router address from the list and add it to the "Allowed List" (which is also on the Blocked Clients window). This will prevent the problem for happening again in the future. And with the address permanently allowed, you can leave "Automatic Hack Recognition" enabled, so that it can be enforced for those services for which Rumpus is able to determine proper client IP addresses.
If you need to disable hack attempt recognition, or add the local proxy or router address to the allowed list, don't worry... As long as you use other common sense security precautions (as described in the "Server Security" article in the Rumpus package), including use of non-trivial passwords, disabling this feature has very little impact on overall server security.