Thomas Sapp wrote:
Here's one for you, I checked my system this morning and the hard drive was going nuts. Here is the begining of the log information:
Jul 17 07:40:43 Raisor vsftpd(pam_unix)[4691]: check pass; user unknown
Jul 17 07:40:43 Raisor vsftpd(pam_unix)[4691]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:46 Raisor vsftpd(pam_unix)[4695]: check pass; user unknown
Jul 17 07:40:46 Raisor vsftpd(pam_unix)[4695]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:46 Raisor vsftpd(pam_unix)[4697]: check pass; user unknown
Jul 17 07:40:46 Raisor vsftpd(pam_unix)[4697]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4701]: check pass; user unknown
Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4701]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4703]: check pass; user unknown
Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4703]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4707]: check pass; user unknown
Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4707]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4709]: check pass; user unknown
Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4709]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4713]: check pass; user unknown
Jul 17 07:40:47 Raisor vsftpd(pam_unix)[4713]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4715]: check pass; user unknown
Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4715]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4717]: check pass; user unknown
Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4717]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4721]: check pass; user unknown
Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4721]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4723]: check pass; user unknown
Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4723]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4727]: check pass; user unknown
Jul 17 07:40:48 Raisor vsftpd(pam_unix)[4727]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:49 Raisor vsftpd(pam_unix)[4729]: check pass; user unknown
Jul 17 07:40:49 Raisor vsftpd(pam_unix)[4729]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:49 Raisor vsftpd(pam_unix)[4733]: check pass; user unknown
Jul 17 07:40:49 Raisor vsftpd(pam_unix)[4733]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14 Jul 17 07:40:49 Raisor vsftpd(pam_unix)[4735]: check pass; user unknown
Jul 17 07:40:49 Raisor vsftpd(pam_unix)[4735]: authentication failure;
logname= uid=0 euid=0 tty= ruser= rhost=81.201.142.14
and this continues to fill up my system log until this morning at 5:45AM when I disabled the vsftpd service. I had only started it because I needed a file from my computer at home while I was at work and forgot to disable it last night! that'll teach me! Anyone know of any exploits that this uses? There are no changed or weird files and a login was never succeded from this attempt. the ip address that was being used changed 3 times but it stayed on the same subnet. I blocked the entire subnet but was wondering if anyone had any suggestions on what to check on my system for possible intrusion?
You could boot from a rescue cd and run "chkrootkit" although from the logs above it appears this was simply a scripted attack that failed. There are automated programs that scan IP blocks for open ftp servers and automatically launch attacks to anything they find in the hope that the server can be exploited for warez, pr0n, etc.
If you need to transfer files in the future, you may want to use something other than ftp (e.g., "sftp" or "scp" from the OpenSSH package).
If you simply must use ftp, configure iptables to only accept connections to ports 20 and 21 from known IPs; that is, the IP address or block for your work machine.
If you use xinetd to launch the ftp server on demand, you can define rules to restrict access in a number of interesting ways.
Also check your tcp_wrapper rules. Most modern ftp servers for linux are compiled with tcp_wrapper support, which can add another layer of control/security to the transaction.
--
-John (john@xxxxxxxxxxx)
