Flood of server hammering after sending out an email. Suspicious?

[superboyac]

So, check this out.  I set up a private file server.  Nobody knows the address or anything, it's just for me.  I created a user profile for someone, and I emailed him (using gmail pop access) the login information.  Right after that, a bunch of ip's have been trying to get into the server using all sorts of usernames and passwords.  None of them have worked, but I'm wondering...if you send an email, is that just open for the world's hackers to read?  These ip's are all in asia or europe (mostly asia).  Pretty interesting.

[Josh]

Is this FTP? If so, it is normal. There are thousands of probes daily on just about any service you can setup. My home FTP server gets hit daily by about 20-30 random attempts to login. I suggest securing access by locking down the max number of attempts per 30-60 seconds, max # of accesses/sessions per ip, etc.

[superboyac]

Is this FTP? If so, it is normal. There are thousands of probes daily on just about any service you can setup. My home FTP server gets hit daily by about 20-30 random attempts to login. I suggest securing access by locking down the max number of attempts per 30-60 seconds, max # of accesses/sessions per ip, etc.

-Josh (December 18, 2011, 07:00 PM)

Cool, thanks.

[skwire]

Running it on a non-standard port will help as well.

[f0dder]

The timing is probably a coincidence, but yes - sending email does largely mean your message is available in plaintext across the internet. Even if you and your recipient have encrypted connections to your respective endpoints (smtp for you while sending, pop3/imap/webbased-whatever for him receiving), there's no guarantee that intermediary SMTP servers will do encrypted traffic.

Please don't expose FTP servers to the internet, the protocol sucks and so many of the ftp daemons are riddled with security holes. Set up an SSH server so you can do SCP (there's decent enough Windows GUIs for it), and it lets you authenticate securely via public-key encryption (remember to turn off password-based SSH access, that way you're not bruteforceable).

Oh, and if this is a linux server, install something like fail2ban. It monitors log files for suspicious activity, and firewall-blocks IPs (temporarily or permanently) according to various rules - it's good stuff.

At any rate, on a server that's exposed to the internet, make sure it's NAT'ed to only let the specific ports you need through.

[Renegade]

Running it on a non-standard port will help as well.

-skwire (December 19, 2011, 12:17 AM)

+1 - A very good recommendation!

[Stoic Joker]

I've got a selection of diagnostic utilities that (frequently get deleted from my ThumbDrive by someones hyper-spastic AV software) I keep in a subfolder of our webserver for quick access. Its come in handy many times (I really hate AV software). Obviously these aren't sensitive files, but it does work in a pinch - depending on your needs.