Securing FTP server - up for 3 days and already attempted hack

Five_Star · 22 Mar 2010 at 09:27

Last week I was asked to setup a FTP server as we are going to start receiving a lot of information from publishers and print companies. I did try and explain the negative points of running an FTP server, especially as I’m no network admin and this is the second part of my job but I was assured by management it would be OK and these people only know how to use good old FTP.

Anyway I got a fresh VM build using server 2008 R2 standard, it is not joined to the domain. I setup IIS 7.5 and created the FTP users locally on VM using random user names and 12 character passwords with upper and lower chars, numbers and selected special characters.

I managed to get the ASA 5505 we have to accept passive connections using the FTP inspection maps as I was going to run the FTP in active mode at first but some of the publishers didn’t seem to understand how to connected in active mode.

I’ve come in today and checked over the FTP server (mainly to see if anyone is using it) and found this in the logs

Code:

2010-03-20 14:23:14 201.30.62.210 - xx.xx.xx.xx 21 USER access 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:15 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:17 201.30.62.210 - xx.xx.xx.xx 21 USER account 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:17 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:23 201.30.62.210 - xx.xx.xx.xx 21 USER accounts 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:24 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:24 201.30.62.210 - xx.xx.xx.xx 21 USER adam 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:24 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:28 201.30.62.210 - xx.xx.xx.xx 21 USER adm 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:28 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:34 201.30.62.210 - xx.xx.xx.xx 21 USER admin 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:35 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:39 201.30.62.210 - xx.xx.xx.xx 21 USER admin2 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:40 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:40 201.30.62.210 - xx.xx.xx.xx 21 USER admin2 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:41 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:48 201.30.62.210 - xx.xx.xx.xx 21 USER adrian 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:48 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:49 201.30.62.210 - xx.xx.xx.xx 21 USER adrian 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:49 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:50 201.30.62.210 - xx.xx.xx.xx 21 USER aerial 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:50 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:54 201.30.62.210 - xx.xx.xx.xx 21 USER agent 331 0 0 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -
2010-03-20 14:23:54 201.30.62.210 - xx.xx.xx.xx 21 PASS *** 530 1326 41 50dc99c1-32bb-4370-ab1b-dd71efd0e782 -

And then this

Code:

2010-03-20 19:43:09 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:10 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:11 147.175.133.11 - xx.xx.xx.xx 21 USER Administrator 331 0 0 87538c0c-081d-4091-a1ff-4eacab96c80f -
2010-03-20 19:43:11 147.175.133.11 - xx.xx.xx.xx 21 PASS *** 530 1326 41 87538c0c-081d-4091-a1ff-4eacab96c80f -

What other steps can I use to protected this FTP server, its only been up for 3 days and attacked twice! I’m not sure how long it will last before somebody with more experience in this matter finds a hole and the machine is compromised.

daz · 22 Mar 2010 at 09:31

This is pretty normal... In Linux, you'd use a login failure daemon to monitor logins to FTP and add any IPs with more than, say 10 failures to a firewall block list.

Make sure anonymous FTP access is disabled as well.

FTP is an inherently insecure protocol though, so your best bet is to lock it down to a VPN range and have users log-in to a VPN before they can access FTP.

DiscoDave · 22 Mar 2010 at 09:56

If security is an issue you can set up SSL over FTP. I've done this with filezilla. Worked really well with a self-generated certificate (can do it through filezilla)

Five_Star · 22 Mar 2010 at 10:08

Thanks for the quick replies, there is even another probe happening right now.

There is no anonymous access enabled, only the users in the local FTPuser group are allowed to login. The server is set to accept both SSL and non-SSL connections but not everyone connects with SSL on (some of the publishers don't have a clue)

Should I be looking at a separate FTP server for Windows that offers some nicer features? IIS FTP doesn't allow you to limit login re-trys on failure which would at least slow these guys down.

How much mileage is there in getting a list of IP ranges from these publishers and only accepting connections from those, is this a good solution?

GhostlyPea · 22 Mar 2010 at 10:18

What FTP server are you using? Implementations like Filezilla can automatically ban IP addresses after a failed number of connections

- Pea0n

bigredshark · 22 Mar 2010 at 10:33

It's perfectly normal for an internet facing system...

-bash-3.2# cat /var/log/secure |grep "Failed password" |wc -l
3657

That's just today...my only advice is to make sure the default usernames don't have access and enforce strong passwords. The attacks are undirected and frequently just try 'root' or 'admin' users. If they have to guess the username at random as well as the password the chances of success basically disappear.

You could implement one of various options to ban addresses after a number of retries but personally I think it's not worth the effort, the attacks are unsophisticated and not worth paying attention to if your security is any good at all.

m4cc45 · 22 Mar 2010 at 10:46

What we do is use SFTP and then, on the firewall, allow only the originating IP's acces so if anyone else trys to gain access the firewall drops them. Yes it's a little more work to add new IP's but we now do this as part of the process (so IP, username, password are now required instead of just making a username and password).

Just an extra layer of protection.

M.

bigredshark · 22 Mar 2010 at 10:58

m4cc45 said:
What we do is use SFTP and then, on the firewall, allow only the originating IP's acces so if anyone else trys to gain access the firewall drops them. Yes it's a little more work to add new IP's but we now do this as part of the process (so IP, username, password are now required instead of just making a username and password).

Just an extra layer of protection.

M.

Pity so few ISPs implement serious spoofing protection in their networks, assuming that locking down to IPs gives you security is a dangerous bet and for internet facing systems I think it's an unnecessary effort - either just open it up with decent authentication, or close it off completely and use VPN access (with SSL VPN becoming the mainstream standard this is even more true now).

unp|dissy · 22 Mar 2010 at 11:01

Change ftp's port to something random, they're not 'hacks' as such but merely infected bots trying to auto connect to your machine by port 21..

Job done.

Oh, and i'd suggest:

use vsftpd in linux - a lot more secure.
Disable root access to your ftp (or admin access if your need to run winblows..)
Have one user for ftp (but do not allow the ftp user to have a shell login)

unp|dissy · 22 Mar 2010 at 11:04

m4cc45 said:
What we do is use SFTP and then, on the firewall, allow only the originating IP's acces so if anyone else trys to gain access the firewall drops them. Yes it's a little more work to add new IP's but we now do this as part of the process (so IP, username, password are now required instead of just making a username and password).

Just an extra layer of protection.

M.

Very good idea to implement this too.

m4cc45 · 22 Mar 2010 at 11:12

bigredshark said:
Pity so few ISPs implement serious spoofing protection in their networks, assuming that locking down to IPs gives you security is a dangerous bet and for internet facing systems I think it's an unnecessary effort - either just open it up with decent authentication, or close it off completely and use VPN access (with SSL VPN becoming the mainstream standard this is even more true now).

It's more secure than leaving it open. SFTP + Secure Logins / Passwords + Locked down Firewall = more secure than just allowing any one to scan it and then have an immediate point of entry.

M.

bigredshark · 22 Mar 2010 at 13:05

unp|dissy said:
Change ftp's port to something random, they're not 'hacks' as such but merely infected bots trying to auto connect to your machine by port 21..

Job done.

Oh please don't, security through obscurity isn't actually security at all and annoys the hell out of people.

It's no extra defense against somebody with even a hint of ability and no real extra defense against automated attacks over a strong username and password.

bigredshark · 22 Mar 2010 at 13:10

m4cc45 said:
It's more secure than leaving it open. SFTP + Secure Logins / Passwords + Locked down Firewall = more secure than just allowing any one to scan it and then have an immediate point of entry.

M.

Really? I disagree personally, decent authentication is better security than limiting access by IP against a determined attack and doing something which gives the illusion of security but is (currently) fundamentally flawed is very dangerous because it makes people think the system is secure whether it is or not.

Sure defense it depth is a good idea most of the time but not at the expense of making users lives harder (and plenty of users will have dynamic ISP assigned IPs...). If you're worried use a VPN...

m4cc45 · 22 Mar 2010 at 14:57

bigredshark said:
Really? I disagree personally, decent authentication is better security than limiting access by IP against a determined attack and doing something which gives the illusion of security but is (currently) fundamentally flawed is very dangerous because it makes people think the system is secure whether it is or not.

Sure defense it depth is a good idea most of the time but not at the expense of making users lives harder (and plenty of users will have dynamic ISP assigned IPs...). If you're worried use a VPN...

If I can port scan your IP and find a service running on it then I know:

A. The service exists
B. It's a common service (such as FTP running on port 21 requesting a login ID)
C. Chances are it's not been configured to stop telling the World the version of the software so there could be exploits based upon the software versions, especially if it's out of date.

Most bots are designed to test a range of IP's for common ports so if they don't see them as open they will move to the next IP and carry on. If it's a direct attack then, again, giving the attacker less information is better than advertising to them that a service exists and there is no IP restrictions.

Having 20 VPN's just for a SFTP site is unrealistic. Locking it down to IP's is not making it harder or much more work. We're talking corporate users here with static IP's and even if there IP changes in the future it's a very minor change.

For an extra 1 minutes work per connection it's easier to lock it down as much as possible.

M.

bigredshark · 22 Mar 2010 at 16:00

m4cc45 said:
Having 20 VPN's just for a SFTP site is unrealistic. Locking it down to IP's is not making it harder or much more work. We're talking corporate users here with static IP's and even if there IP changes in the future it's a very minor change.

Really, the OP hasn't said it's corporate users, the fact he's asking for advice here suggests it isn't and if it was they would be a) using VPNs and b) not using FTP at all.

ThomP · 23 Mar 2010 at 10:30

I have the same issue as the OP with ftp and many other services. The way I resolved it, using a unique range of usernames not the typical "thomas", "frank" type usernames. Auto banning of IPs & abusive Netblocks after X attempts. Implemented IDS + IPS on my network, with network weather mapping. If it needs to be more secure then clients VPN into a staging area then access other services.

Five_Star · 23 Mar 2010 at 11:22

Unfortunately it is for corporate users. Most of the publishers have static IPs but nearly half are really small independents, some even working from home with no real IT infrastructure. I would really like to use an IP whitelist but for the dynamic IP publishers I can’t.

It seems that they have been using FTP since the dawn of time and are happy with it, but again only some of them can manage to connect on FTP over SSL and its been made clear by management that we are to pander to the publishers needs as we really need their content and I should make it as easy as possible for them.

We do have a VPN for remote access on weekends and the guys at the US office to remote in on, I’m not so sure about extending that to allow publishers to connect in on it as well, we’d have to send them all out a security woggle too and I’m sure that would be far too difficult for them to use.

I hope that FTP is a short term problem for us, I’m managing it daily checking the logs etc and will be changing the publishers passwords monthly. I’m currently working on our own internal application that allows the publishers to send files to our cloud storage for processing, once thats out we can stop running FTP.

It’s been really good to get some opinion on what security to put in place, for now I think we’ll have to run with a locked down FTP box, random usernames, 12 character passwords on monthly change and daily access log checks.

bigredshark · 23 Mar 2010 at 11:54

Five_Star said:
It’s been really good to get some opinion on what security to put in place, for now I think we’ll have to run with a locked down FTP box, random usernames, 12 character passwords on monthly change and daily access log checks.

And that's all you really need, so long as you remember that random usernames will encourage people to write them down...