<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2><div><font color="#990099">-----kwlug-disc-bounces@kwlug.org wrote: -----<br></font>>So no firm answer is possible, but it sounds like I'm 'probably'<br>>safe.  This was an automated attack, not an individual actively logging on. <br>>I guess I'll leave it for now, and work on doing a complete server wipe<br>>which is long overdue.<br>><br>>Going forward, the only person who ftp's on to my server is this<br>>user.  Everyone else - which consists of myself and my developer - do any <br>>server stuff from command line linux.  Is there any benefit from my <br>>forcing my friend to use ssh to access the server instead of ftp? <br>>He's on a windows box so he'd have to find some software.  I installed an<br>>ftp daemon for his benefit and didn't like it at the time.<br><br>"Probably safe" is correct but you should do some due diligence to ensure that all is okay.<br>The people that say "nuke it from space" are suggesting that there is no way to know for sure without re-installing. I believe this is overkill for most people and small companies. From an absolutely paranoid point of view the is no certainty of security in anything. Those people are trusting that the distro and their data (backups?) are clean. I'm just as confident that a system can be cleaned of hacks, at least the garden variety hacks.<br><br>Spending 4 hours to clean a hacked system may be more desirable than taking 16 hours of reconfiguration and down time. Sufficiently paranoid people won't trust their own data after an attack. Restoring from backup may add more time and involve data loss as well.<br><br>Zixiekat's comments about chrooted ftp is sound and recommended. vsftp provides that functionality without much effort. You might also consider use TLS or SSL on FTP as well since FTP passes passwords in clear-text.<br><br>If your package manager supports file verification use it. RPM based systems can use "rpm -Va". Save the output and manually inspect all the changed files. It will be a big list and many files are config files and can often be ignore. Then check /etc/ and subdirs for new files. These would be  *.d directories like /etc/init.d or /etc/cron.d /etc/cron.hourly.d. Check /var/spool/cron as well for new cron files. Inspect root's profiles and other users profiles.<br><br>If you find ls, netstat, ps, top, find or other binaries have been replaced then you've had a rootkit installed. If so re-install the packages those file belong to and recheck their authenticity. Once thye have been cleaned up look in /dev for actual files (find /dev -type f) or look in /lib or /usr/lib for odd directories. This is often where an attacker will keep files.<br><br>Look for new users in /etc/passwd and check the time stamp on /etc/passwd and /etc/shadow. Compare these against /etc/passwd- and /etc/shadow- to see what the last change was.<br><br>Practically speaking it's common to see root kits and hacks that don't use root kits and ones that add a user. I've never yet seen one that adds files to /etc/*.d. A while ago I found one that added an inetd entry. That may give you some idea of when to stop looking.<br></div></FONT>