![]() If the bad code that is appearing on your pages (or the iframes or JS that loads the bad code from a remote site) cannot be found anywhere in your site, then your host will need to investigate the possibility of a server-wide compromise. Keep in mind, the power of Google hacks originates from the numerous combinations that can be used. For example, users can find Excel files where you may have stored numerous email addresses by exploiting this hack: filetype:xls inurl:email.xls. If you use PHP or ASP or any other server side scripting language, you'll need to study how to code securely in that language. You can easily find email lists through simple Google hacking techniques. If you use a wireless internet connection, use only encrypted SFTP to access your site. Scan your PC with antivirus software other than the one you normally use. It does not sound like you and your host have truly discovered how this happened, and it's unlikely this episode is really over. ![]() It overlooks many aspects of server/site security, and there are lots of ways someone can hack your site. In your other thread here, you asked: "my host says that if i change my ftp password, as well as change my password to access my account directly through the host, and then i also set up ftp.allow to only allow my IP address to ftp to my site, that i am covered against hackers." Those are 3 security improvements you can do, but it does not in any way "cover you against hackers". If the host found malicious iframes and removed them for you, they did you a favor, but it did not address the question of how the pages were modified to contain iframes in the first place, so the hacker will simply put them back. If the FrontPage Extensions were properly configured and the folder permissions also correct (usually the case), the FPE wouldn't be the weak spot, either. The hack apparently modified your static pages, but that was almost certainly not the avenue of the original entry. Old FrontPage code in your static pages would not be hackable. In other words, it would be fake code (for example, a script whose source is something like gooqle-analytics (notice the Q) or googleanalytcis), and it would be inaccurate to say that "the infection occured in the google analytics/urchin script". It is most likely that the hack added different, malicious, code to the bottoms of your pages that looked like Google Analytics / Urchin code but wasn't.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |