|Yea, I think they give a general worse case scenario for an infected website. But in my case, it looks like someone has found a specific use for infected websites. |
I'll pm my logging events.. if iptables or the hosts.deny thing where I can dump a list of IP's, i can easily idendify them
EDIT : I misunderstood ... your credentials were not compromised , so read the following as an exercise of good practice.
The " last " command shows the loggin events : they appears as in the following template :
<username> <local/remote console number> <source*> <date> <duration>
* the source is an IP for remote logins or the screen number for local graphical logins ( not your case )
The information is stored in /var/log/wtmp file , but usually, in most linux distributions , is subjected to a periodically cron based log rotation.
In case of ssh , it's better allowing remote access only to normal users and permanently deny root accesses : root access can be still possible with "su" command and/or with "sudo" ...
In Debian root login through ssh are denied by default.
Root login through ssh is denied by default also in FreeBSD but "su" or "sudo" access are denied by default unless the user is not in the wheel group or in the sudoers respectively.
Someone has suggested for first to configure user than can access to ssh , upload the ssh keys and then disable the password based login.
Configuring a vpn or a vpn+ssh based remote access to do all that is needed ( administration , file upload ... ) and disable all the other remote login daemons could be the last ( for now ) better solution.