Here are some tips to keep your site secure. This was primarily written in response to a hacked site: 1. First thing you need to do is check all vendor/developer sites for ALL web scripts/applications used in your account for any updates including any mod you may be using in any web application. If you are using any open source web application, that may be the prime suspect. However, you must check all and keep them up to date. Check the database on www.secunia.com for any known exploits released in public. 2. Once you have verified that 100% of the installed scripts are the latest stable version, you will need to go through all files of your account and make sure none were uploaded by hackers before you audited or left by you from an old install of an application. There may be suspicious files in folders you would never imagine and in folders several levels down. You can use ftp or cPanel file manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup.] 3. Make sure all passwords are a mix of alpha-numeric and not a dictionary word. Just because you thought of a difficult word from the dictionary does not make you safe. Please also use both capitals and lowercase and at least 8 characters. 4. The MySQL database access to all web applications should be using separate db users. Do not ever use your main account user/pass for it. Your main user/pass should never be stored in any file in your account. 5. In your control panel, activate archive option of your web logs in Raw Log Manager. This will give you the opportunity to check how the hacker exploited one of the scripts. Otherwise all raw logs are cleared after generating stats. If you have already been hacked, its too late now but you can archive the logs for future attacks. 6. If you have customized a web application with a mod, make sure it is also the latest stable version. Many popular web application may be stable but one of the addon mods may be exploitable and possibly not maintained any more. 7. If you have written some code yourself, make sure all input variables are sanitized (checked for valid data before using it). Otherwise a single line of bad code can give access to your entire account. The usual blunder is to include a file based on user input. Again, make sure all input to a script is checked for valid data. All exploits are based on input data. If your site does not take any input, you are 100% safe from web exploits, i.e. if you run 100% static HTML site with no script whatsoever anywhere in your account. 8. For PHP, any application that uses register_globals to be active has more chances of being exploitable. Avoid such applications. 9. If you have some mail script, make sure it is safe from header injection. In essence make sure that email address, subject and other part of data that is being submitted by user does not contain line breaks. Some coding assistance is provided on our forums. 10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account. 11. If your site has been running fine for years, it does not mean there were no security holes in it. It actually means that exploit was unknown or you were lucky that no one exploited it before. 12. For added security, change the permissions of your configuration files (having database credentials etc.) to 660. You can do that via ftp or file manager. This feature can work on shared hosting servers or if your VPS/dedicated server has phpsuexec through cPanel. 13. For added security, if you can block access to certain administrative sections of your site, do that by giving access to only authorized IP addresses and blocking access for everyone else, Or password protect it. 14. If there is any file upload facility in your account, make sure that only authorized members can use it. Also the uploaded file should not be accessible via web URL directly (i.e. stored outside of public_html) unless a) it is only uploaded by a site admin (responsible person) b) checked and validated to be not exploitable 15. If there is any URL forwarding or Webmail facility for your site membership, make sure it is not given to all without proper authorization or it could be used for spamming. 16. If you’re just testing / trying something, which only you need and you know you won’t actively keep up to date, just lock it behind a password right away. 17. Since shared/sdx/reseller servers come with suPHP, you do not need any file or folder with world write permissions. The normal folder permissions should not exceed 755. PHP/HTML files can be 644 (or lower through ssh). CGI/Perl scripts should be 755.

Prevent HackingHacked AccountGoogle Attack Page The most important thing to do is keep your passwords a secret. If you must give a password to someone, don’t share it with too many people, and be sure to change it when they are done using the access. Don’t write down your passwords or save them in a plain text file. I highly recommend you periodically change your passwords. You can find more by searching “How can I make a stronger password?” Along the same idea, you need to make sure your personal computer does not have viruses, trojans, keyloggers, etc. Keep your scripts and downloaded programs updated. Always upgrade to the latest version of your blog, forum, shopping cart, etc. Do not have writable file permissions. The correct permissions are normally 755 or 644, and you can check these in your File Manager. Most users know to avoid 777 permissions, but you really want to avoid any permission settings which allow Group and World writing. (That’s anything ending in 7, 6, 3, or 2. The first number can be one of these, but not either of the last two numbers.) Never leave scripts on your account that are not being used. These tend to be forgotten and since they are no longer maintained they are often out of date and can pose a very serious security threat on your account. If you no longer need the script it is best to download your backups and remove it from the server.

Start Outlook Express Click on Start->Program->Outlook Express and see screen Picture Step by Step http://pkwebhost.net/how-to-configure-outlook-with-your-domain-mail.html

We will migrate up to 100 clients free of charge for any reseller client who signs up for any Reseller, VPS or Dedicated server plan. – cPanel Accounts with data above 25 GB will not be migrated on reseller hosting only – There is no limit on the number of packages that can be migrated – However, for Reseller Hosting, we will only be able to migrate packages with a maximum of 100 Accounts under it – Packages with more than 100 Accounts will be charged based on the number of accounts that need to be migrated (Usually $1 per account) – If you have an existing Reseller Hosting package, we will migrate cPanel accounts for free. – We will only be able to migrate cPanel main account with all data including all domain