As for ssh, I would try to do a few things other than just change the port, just to be safe. You may already do a few of these, but a couple I think you have mentioned in the past you do not do.
Key based authentication is going to be a help in preventing someone from gaining access, a key is always going to be longer than a password/passphrase. AllowUsers/AllowGroups to a username and host if you can. Having sshd listen on an IP other than something you can easily guess is going to help. Just as an example if you had it set to the default of any host or set to nobaloney.net or the IP that resolves to, and I wanted to try to break in, I would start with 'ssh nobaloney.net' or even mine all subdomains and domains that might be hosted on the IPs of your machines. If nobaloney.net resolved to 72.2.1.3 and you could have ssh listen on an IP that no dns entry would resolve to it add one more guess into the mix, especially if the IP was nowhere near the one for nobaloney.net, like 65.21.4.56. For the router at my house I have it set so I can only ssh from work or from a remote VPS and the VPS prevents only a certain user logging in from my work IPs and only a certain user when logging in from an unknown location. I don't know how many servers you have or if your clients need to ssh into them, but one of the better solutions would be to setup a small gateway server either at that facility or a VPS somewhere and make it a very minimal install like OpenBSD or something else that is secure. Make that a gateway server that chroots ssh so that the only thing the user can do is ssh into another machine and nothing more. If that machine was in the same facility you could use private addresses and have sshd on each of your servers only listen on the private addresses. This would make it one point of contact for external ssh and that mixed with syslogd or any remote logging will help security a great deal. Especially with openbsd's security! I don't know that you would fine anything in secure because if this person knew what they were doing they would have probably removed the entries, syslogd would help a little by adding another layer between them and the logs. Sorry for the long email, just wanted to provide info that might help down the road. On Tue, Nov 25, 2008 at 5:33 PM, Peter Manis <[email protected]> wrote: > Jeff, > > Just as a note for the future, you can get by setting up a cronjob by using > watch > > watch "ps aux | grep check.cgi | awk '{print $2}' | xargs kill" > > would find and kill every pid linked to check.cgi. By default watch runs > every 5 seconds, but you can change that with -n. You can either append & > on it to have it run in the background or use screen so that it will > continue to run even if you disconnect. > > > On Tue, Nov 25, 2008 at 4:32 PM, Jeff Lasman <[email protected]>wrote: > >> On Tuesday 25 November 2008 01:18 pm, David Kaiser wrote: >> >> > Well, it is possible that some process was able to change it's >> > process info to read "/usr/bin/perl -w./check.cgi" when there was no >> > check.cgi file anywhere. Just a decoy trick from a bad process. >> >> Perhaps ... >> >> My additional post with more information never made it to the list. >> Let's see if this one does. Maybe I'm ending up on blocklists used by >> this list <frown>... >> >> In the meantime I was rounding a per-minute cronjob to kill check.cgi >> each time it found it ... now I've turned that off and will see if any >> show up again so i can check as you suggested. >> >> Jeff >> -- >> Jeff Lasman, Nobaloney Internet Services >> P.O. Box 52200, Riverside, CA 92517 >> Our jplists address used on lists is for list email only >> voice: +1 951 643-5345, or see: >> "http://www.nobaloney.net/contactus.html"; >> _______________________________________________ >> LinuxUsers mailing list >> [email protected] >> http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers >> > > > > -- > Peter Manis > (678) 269-7979 > -- Peter Manis (678) 269-7979
