FTP accounts not working ....

17 posts / 0 new
Last post
#1 Tue, 01/18/2011 - 01:19
Gary
Gary's picture

FTP accounts not working ....

hi Folks,

just migrated over to a new VM server. All domains were exported and imported at the new server without too many difficulties.

One odd problem though: some user FTP accounts I created are not able to log in. I can log into each of those user accounts on different domains no problem thru Dreamweaver or CuteFTP, but my clients, located in different cities are locked out of FTP logins they were able to use no problem on the old server. I have tried re-creating the accounts, but no help.

If anyone could suggest any possible fix for me, that would be great.

thanks,

Gary

Tue, 01/18/2011 - 07:37
andreychek

Hi Gary,

The key would be to look in the logs to figure out what's going on.

Which logs, exactly, would depend on the distribution you're using. On CentOS, I'd look in /var/log/secure and /var/log/messages. On Ubuntu/Debian, you'd want to look in /var/log/syslog.

There may be other logs that help too, but those should be a good start :-)

Try logging in as once of those accounts, when it fails, take a look at the logs and see if there's any relevant messages.

-Eric

Tue, 01/18/2011 - 09:11
Locutus

/var/log/auth.log is also a good idea for authentication trouble.

Wed, 01/19/2011 - 21:37
Gary
Gary's picture

thanks Eric & Locutus for your suggestions ...

using Webmin's File Manager, I found there were files called "messages" and "secure" under var/log/ ... but no file called "auth.log" ....

Since the file logs seem to only go back 3 days, I will have to ask my clients to re-try their ftp failures once again.

However, I did come up with a lot evidence of what looks like hacking attempts. Since there is no specific forum on security issues, I will post some samples here, and ask what I might do for preventative measures.

Out of about ten thousand entry lines of var/log/secure, spanning only 3 days, about one-third of the entries seem to be some kind of port-scanning or ssh break-in attempts. Is this type of thing normal for servers? Do hackers just randomly choose servers and keep going at it? (what a creative way to spend your life!)

Here's some samples of the entries. Is there any point in blocking IP's (when they are likely spoofed), or, say, only allowing logins or SSH from IP's that our own side might be using?

thanks for any comments or advice...

Gary

====================SAMPLES: VAR/LOG/SECURE====================

Jan 16 08:52:12 cd4502 sshd[6789]: Invalid user git from 8.20.136.233 Jan 16 08:52:12 cd4502 sshd[6792]: input_userauth_request: invalid user git Jan 16 08:52:12 cd4502 sshd[6789]: pam_unix(sshd:auth): check pass; user unknown Jan 16 08:52:12 cd4502 sshd[6789]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=8.20.136.233 Jan 16 08:52:12 cd4502 sshd[6789]: pam_succeed_if(sshd:auth): error retrieving information about user git Jan 16 08:52:14 cd4502 sshd[6789]: Failed password for invalid user git from 8.20.136.233 port 33115 ssh2 Jan 16 08:52:14 cd4502 sshd[6792]: Received disconnect from 8.20.136.233: 11: Bye Bye Jan 16 10:50:45 cd4502 sshd[16609]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.212.150.232 user=root Jan 16 10:50:46 cd4502 sshd[16609]: Failed password for root from 210.212.150.232 port 42549 ssh2 Jan 16 10:50:47 cd4502 sshd[16612]: Received disconnect from 210.212.150.232: 11: Bye Bye Jan 16 10:50:50 cd4502 sshd[16613]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.212.150.232 user=root Jan 16 10:50:52 cd4502 sshd[16613]: Failed password for root from 210.212.150.232 port 42951 ssh2 Jan 16 10:50:53 cd4502 sshd[16616]: Received disconnect from 210.212.150.232: 11: Bye Bye Jan 16 10:50:56 cd4502 sshd[16621]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=210.212.150.232 user=root Jan 16 10:50:58 cd4502 sshd[16621]: Failed password for root from 210.212.150.232 port 43364 ssh2 Jan 16 10:50:58 cd4502 sshd[16624]: Received disconnect from 210.212.150.232: 11: Bye Bye Jan 16 19:07:15 cd4502 sshd[27471]: reverse mapping checking getaddrinfo for 188-95-51-71.thefreevps.com failed - POSSIBLE BREAK-IN ATTEMPT! Jan 16 19:07:15 cd4502 sshd[27471]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=188.95.51.71 user=root Jan 16 19:07:16 cd4502 sshd[27471]: Failed password for root from 188.95.51.71 port 51258 ssh2 Jan 16 19:07:16 cd4502 sshd[27474]: Received disconnect from 188.95.51.71: 11: Bye Bye POSSIBLE BREAK-IN ATTEMPT! Jan 17 05:31:34 cd4502 sshd[17062]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=201.243.137.209 user=root Jan 17 05:31:36 cd4502 sshd[17062]: Failed password for root from 201.243.137.209 port 2502 ssh2 Jan 17 05:31:36 cd4502 sshd[17065]: Received disconnect from 201.243.137.209: 11: Goodbye Jan 17 05:31:44 cd4502 sshd[17066]: Address 201.243.137.209 maps to 201-243-137-209.dyn.dsl.cantv.net, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT! Jan 17 07:09:14 cd4502 proftpd[25811]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - USER drudoman (Login failed): Incorrect password. Jan 17 07:09:14 cd4502 proftpd[25811]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - FTP session closed. Jan 17 07:09:15 cd4502 proftpd[25812]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - USER wwwdrudomancom: no such user found from 208.98.22.226 [208.98.22.226] to 208.78.241.87:21 Jan 17 07:09:15 cd4502 proftpd[25812]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - FTP session closed. Jan 17 07:09:15 cd4502 proftpd[25813]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - USER www.drudoman.com: no such user found from 208.98.22.226 [208.98.22.226] to 208.78.241.87:21 Jan 17 07:09:17 cd4502 proftpd[25813]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - FTP session closed. Jan 17 07:09:18 cd4502 proftpd[25814]: 208.78.241.87 (208.98.22.226[208.98.22.226]) - USER drudomancom: no such user found from 208.98.22.226 [208.98.22.226] to 208.78.241.87:21 Jan 19 00:08:28 cd4502 sshd[20727]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=168-215-227-26.static.twtelecom.net user=root Jan 19 00:08:30 cd4502 sshd[20727]: Failed password for root from 168.215.227.26 port 53843 ssh2 Jan 19 00:08:30 cd4502 sshd[20730]: Received disconnect from 168.215.227.26: 11: Bye Bye Jan 19 00:08:31 cd4502 sshd[20731]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=www.hikinostudentnews.org user=root Jan 16 06:33:09 cd4502 named[1538]: client 62.77.203.10#18132: query (cache) 'domain1.com/MX/IN' denied Jan 16 06:33:10 cd4502 named[1538]: client 213.163.34.66#17362: query (cache) 'domain1.com/MX/IN' denied Jan 16 06:33:10 cd4502 named[1538]: client 213.163.34.66#25850: query (cache) 'domain1.com/MX/IN' denied Jan 16 06:33:10 cd4502 named[1538]: client 213.163.34.66#32643: query (cache) 'domain1.com/MX/IN' denied
Wed, 01/19/2011 - 21:54
andreychek

Howdy,

Is this type of thing normal for servers? Do hackers just randomly choose servers and keep going at it? (what a creative way to spend your life!)

Yup, completely normal! Unfortunately :-)

It's unlikely that's interactive... they're likely bots of some kind, randomly guessing at dictionary passwords.

Good security involves security in layers. However, two of the biggest things I'd suggest for securing your server are making sure your server has all the updates applied, and make sure all the web apps your users have installed are fully up to date. Those are the two most common ways I've seen these bots break in.

However, it certainly wouldn't hurt to verify that your users aren't using simple passwords. Also, some administrators use tools like denyhosts to monitor the logs, and watch for automated attacks such as the ones you saw. After so many incorrect login attempts, denyhosts can block connections from a given IP address. You can read more about it here:

http://denyhosts.sourceforge.net/

There's other alternatives to denyhosts as well, that's just one example in that class of program.

Depending on how many users you have logging in over SSH -- two options for further securing it would be to move it to a port other than 22, and/or to disable password authentication, and require your users to use SSH keys in place of passwords.

Both of those can improve security... it's just a matter of deciding how much inconvenience you and your users want to deal with :-)

-Eric

Thu, 01/20/2011 - 01:58
Gary
Gary's picture

thanks for that Eric.
will look into Denyhosts ... can I install the RPM from inside webmin, can a non-techie like me configure it easily? :)

Here's the output from my recent clients' FTP login attempts; (IP's & usernames changed to protect my clients)

(wasn't sure if the "pam_unix(su:session)" entries in between the login attempts were meaningful or not, so I left them in...)


Jan 19 20:38:25 cd4502 proftpd: pam_unix(proftpd:session): session opened for user billy@mydomain.com by (uid=0)
Jan 20 04:38:25 cd4502 proftpd[30441]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - USER billy@mydomain.com: Login successful.
Jan 19 20:39:42 cd4502 proftpd: pam_unix(proftpd:session): session opened for user billy254.mydomain by (uid=0)
Jan 20 04:39:44 cd4502 proftpd[30457]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - USER billy254.mydomain: Login successful.
Jan 19 20:40:02 cd4502 su: pam_unix(su:session): session opened for user postgres by (uid=0)
Jan 19 20:40:02 cd4502 su: pam_unix(su:session): session closed for user postgres
Jan 19 20:45:02 cd4502 su: pam_unix(su:session): session opened for user postgres by (uid=0)
Jan 19 20:45:02 cd4502 su: pam_unix(su:session): session closed for user postgres
Jan 19 20:45:13 cd4502 proftpd: pam_unix(proftpd:session): session opened for user billy.domain5 by (uid=0)
Jan 20 04:45:13 cd4502 proftpd[30995]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - USER billy.domain5: Login successful.
Jan 20 04:48:26 cd4502 proftpd[30441]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - Client session idle timeout, disconnected
Jan 20 04:48:26 cd4502 proftpd: pam_unix(proftpd:session): session closed for user billy@mydomain.com
Jan 20 04:48:26 cd4502 proftpd[30441]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - FTP session closed.
Jan 20 04:49:45 cd4502 proftpd[30457]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - Client session idle timeout, disconnected
Jan 20 04:49:45 cd4502 proftpd: pam_unix(proftpd:session): session closed for user billy254.mydomain
Jan 20 04:49:45 cd4502 proftpd[30457]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - FTP session closed.
Jan 19 20:50:03 cd4502 su: pam_unix(su:session): session opened for user postgres by (uid=0)
Jan 19 20:50:03 cd4502 su: pam_unix(su:session): session closed for user postgres
Jan 19 20:55:02 cd4502 su: pam_unix(su:session): session opened for user domain2 by (uid=0)
Jan 19 20:55:03 cd4502 su: pam_unix(su:session): session closed for user domain2
Jan 19 20:55:03 cd4502 su: pam_unix(su:session): session opened for user domain2 by (uid=0)
Jan 19 20:55:03 cd4502 su: pam_unix(su:session): session opened for user postgres by (uid=0)
Jan 19 20:55:03 cd4502 su: pam_unix(su:session): session closed for user postgres
Jan 19 20:55:04 cd4502 su: pam_unix(su:session): session closed for user domain2

Jan 20 04:55:14 cd4502 proftpd[30995]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - Client session idle timeout, disconnected
Jan 20 04:55:14 cd4502 proftpd: pam_unix(proftpd:session): session closed for user billy.domain5
Jan 20 04:55:14 cd4502 proftpd[30995]: 145.82.122.23 (222.81.212.14[222.81.212.14]) - FTP session closed.

Jan 19 21:07:37 cd4502 proftpd: pam_unix(proftpd:session): session opened for user cathy@mydomain.com by (uid=0)
Jan 20 05:07:37 cd4502 proftpd[912]: 145.82.122.23 (212.92.124.66[212.92.124.66]) - USER cathy@mydomain.com: Login successful.

Jan 19 21:10:02 cd4502 su: pam_unix(su:session): session opened for user postgres by (uid=0)
Jan 19 21:10:02 cd4502 su: pam_unix(su:session): session closed for user postgres
Jan 19 21:13:02 cd4502 su: pam_unix(su:session): session opened for user domain3 by (uid=0)
Jan 19 21:13:02 cd4502 su: pam_unix(su:session): session closed for user domain3
Jan 19 21:13:02 cd4502 su: pam_unix(su:session): session opened for user domain3 by (uid=0)
Jan 19 21:13:03 cd4502 su: pam_unix(su:session): session closed for user domain3
Jan 19 21:15:02 cd4502 su: pam_unix(su:session): session opened for user postgres by (uid=0)
Jan 19 21:15:02 cd4502 su: pam_unix(su:session): session closed for user postgres

Jan 20 05:17:37 cd4502 proftpd[912]: 145.82.122.23 (212.92.124.66[212.92.124.66]) - Client session idle timeout, disconnected
Jan 20 05:17:37 cd4502 proftpd: pam_unix(proftpd:session): session closed for user cathy@mydomain.com
Jan 20 05:17:37 cd4502 proftpd[912]: 145.82.122.23 (212.92.124.66[212.92.124.66]) - FTP session closed.

Thu, 01/20/2011 - 03:51
Locutus

Eric explained the security implications very nicely there, nothing to add from my end. :)

About the FTP issue, actually I don't see anything wrong in the logs, maybe except for "idle timeout". So, can you please give some more details what "cannot log in via FTP" means exactly? At what stage does using FTP fail in what way? Please give as much information as possible (used software, FTP messages seen etc.)

Thu, 01/20/2011 - 04:19
Gary
Gary's picture

hi Locutus ....

my FTP clients report that they get a "password accepted" message, but don't get the directory listing. That's all I know at this point ...

Gary

Sat, 01/22/2011 - 23:48 (Reply to #8)
helpmin

Some ftp clients require to set the "passive directory" setting (so the client actively changes into the correct directory). One example would be winscp.

Thu, 01/20/2011 - 06:30
Locutus

Okay, then it has nothing to do with authentication. When the control connection works, but data connection does not, It's probably a network related issue. Is the server/client behind a router/firewall/NAT? Do they use active or passive mode? Is ProFTPD correctly configured for firewall operation if needed (passive port range, open those ports in firewall)?

Thu, 01/20/2011 - 08:21
andreychek

will look into Denyhosts ... can I install the RPM from inside webmin, can a non-techie like me configure it easily? :)

If you're interested in pursuing denyhosts, I think my suggestion would be to first set it up in some sort of development environment.

There's always a risk when trying things out on your live server, and you wouldn't want to accidentally lock yourself out of the server :-)

What I did is setup Virtualbox on my desktop (available for free at virtualbox.org), and then setup a Virtual Machine in there that is similar to the server I'm managing. Then, I can do any testing I like inside that Virtual Machine before I go making big changes to my server.

You can use Webmin -> System -> Software Packages to install an RPM. But I'd recommend performing that installation on a test server first :-)

-Eric

Sat, 01/22/2011 - 18:58
Gary
Gary's picture

thanks again guys, for the update on DENYHOSTS etc. Not sure if I have the time & skills to create a test server; would be good to hear from anyone who set up DENYHOSTS on a Webmin/Virtualmin system as to any issues with config or use.

As far as FTP logins failing goes, I thought it might be an issue with usernames not being in lower-case (as I finally found with Dreamweaver: "D'oh! why is my ftp login not working after I've so carefully copied & pasted my ID's?"...)

One of my web-clients who can't presently log in, reports this:

''The problem seems to have to do with Command MLSD or with something after Command MLSD, because what always shows up, at the end of the search, is : Command : MLSD Error: Connection timed out Error: Failed to retrieve directory listing"

as I am not up on FTP command interpretation, not sure what this would mean ...

Sun, 01/23/2011 - 00:08
helpmin

Some ftp clients require to set the "passive directory" setting (so the client actively changes into the correct directory). One example would be winscp.

Sun, 01/23/2011 - 10:42
Locutus

You need passive mode FTP when the client is behind a router and cannot configure port forwarding etc. properly. To give further advice, we'd need to know precisely what the network setup of server and client is, in terms of router and firewalls. Otherwise it's too much to explain here, Google will find better results there. :)

Sun, 01/23/2011 - 10:50
helpmin

Here is an example:

http://winscp.net/eng/docs/ui_login_connection

please try it :-)

Sun, 01/23/2011 - 18:04
Gary
Gary's picture

Well one of my cients had a success by changing "transfer mode" to "active" instead of "default". Another client, "cannot retrieve dir listing / server not responding" prog offers "active/psv" mode, which then brings up a windows firewall warning, blocking some ftp features.

my clients are even less techie than I am, so this is hard for them.

one thing I didn't mention is that my FTP from my machine (Dreamweaver and CuteFTP) work for all these user accounts, but when I toggle "passive" OFF in Dreamweaver, and when I change CuteFTP's data connection type to "port" instead of "pasv" it really speeds up the connection, which was slow on the border of failing with the "pasv" mode enabled.

not sure if this give any more clues. On my previous host, also running a similar Cent OS / webmin/vmin system, none of my clients ever had FTP problems.

thanks for any input!

Gary

Sun, 01/23/2011 - 18:19
Locutus

It's just a matter of correctly configuring ProFTPD and any firewalls/routers in your server's network so the clients can use passive mode. For the server, it's basically two things. You need to configure the passive mode port range and passive mode server IP, and allow those ports through firewall/forward them in NAT router.

To ask again, please give us some detailed information about whether your server and/or clients are located behind a NAT router / a firewall. Depending on that, you need to configure different things to make FTP work (which is - aside from SIP - the most "unthankful" protocol to operate behind NAT).

Additionally, here's some good read about the topic: http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html

Even if this may sound harsh - if you operate a server on the Internet, you should do your best to try and at least basically understand such things, so you have some basic grasp of what the stuff you're running there does. Otherwise you'll constantly be running into trouble. Hope this helps! :)